单元测试应该测什么，不应该测什么？

 　这段代码描述电信营业系统中的缴费开机的过程

　　User user = User.getUserByServiceId("13309790280");//通过电话号码找到用户

　　Account account = user.getAccount();//与用户关联的帐户

　　user.pay(100);//用户缴费100元

　　//判断用户余额＋帐户的信用度-用户欠费是否大于0

　　if (user.getBalance() + account.getCredit() - user.getDebt() > 0)

　　{

　　Service service = user.getService();//与用户相关的服务

　　//判断这个服务是否处于欠费停机状态

　　if (service.getState() == "欠费停机" || service.getState() == "限制呼出")

　　{

　　…//向交换系统发出开机指令

　　}

　　}

　　这是电信营业系统中最常见的的一个业务。电信系统最基础的模型应该说是"三户模型"，三户模型描述的是客户（Customer）、帐户（Account）、用户（User）以及服务（Service）等等概念的一个关系模型。实际的模型比代码里的复杂，这里简化了很多，主要用来举个例子。

　　要开发一个电信系统，首先要做的就是在系统中实现最基础的几个模型，比如三户模型、联机指令模型、业务办理模型、合作伙伴模型……，其中三户模型处于非常重要的地位。首先要做的是在软件系统中真实的反映这个模型，绝不可以将其隐含扩散在各个业务过程中。然后就可以在这个基础上，从一到二、从二到三、从三到万，实现各个子系统和复杂多变的业务需求。

　　按照TDD的开发思路，我们应该先写测试代码，再来写实际程序，用测试来推动开发的前进。这里先把代码写出来，表达一下业务。下面我就说一下，单元测试代码应该测什么。

　　我们拿User举个例子，现在我们要写User类的测试代码。

　　需要测什么？

　　我们需要测试User类的外在表现。比如我们要测试pay方法，应该这样

　　我们建立一个User对象，这个User余额是0，欠费38元。现在缴费100元，缴费完成后，余额应该是62元，欠费应该为0，这是一个Case。

　　我们建立一个User对象，这个User余额是30，欠费0。现在缴费50元，缴费完成后，欠费应该仍然是0，余额应该是80元。这是第二个Case。

　　我们建立一个User对象，这个User的余额是0，欠费150元。现在缴费70元，缴费完成后，欠费应该是80元，余额应该是0。这是第三个Case。

　　我们应该测试的是User类的外在表现，而不应该过问他如何实现。

　　在测试的时候，我们需要一个可以重复的稳定的环境（真实环境往往不行），有时候无法直接建立 User对象（比如User对象要依赖一个数据集），有时候真实的环境很难实现一些测试条件（比如边界值、非正常值）。这时候，我们就可以使用Mock、 Stub这样的方法，把User建立起来，也把环境建立起来，然后测试User的表现。