单元测试，需要基于良好的面向对象设计和类封装。

先写测试，再写代码的好处： 从技术上强制你先考虑一个类的功能，也就是这个类提供给外部的接口，而不至于太早陷入它的细节。这是面向对象提倡的一种设计原则。

没有人能保证需求不变动，以往项目往往对需求的变动大为头疼，害怕这个改动会带来其他地方的错误。为此，除了设计好的结构以分割项目外（松耦合），但如果有了测试，并已经建立了一个好的测试框架，对于需求的变动，修改完代码后，只要重新运行测试代码，如果测试通过，也就保证了修改的成功，如果测试中出现错误，也会马上发现错在哪里。修改相应的部分，再运行测试，直至测试完全通过。

建立单元测试环境。

测试先行、频繁测试、自动测试

　　测试先行，在设计类时，站在调用者的角度去理解类的对外接口，迫使你深入理解类的外在关系，考虑接口的用途，而在具体编写程序时才去具体考虑内部实现细节，这样设计出接口将更易使用，结构也会更趋合理。　　频繁测试，即指测试不应当是阶段性的工作，而应当在程序编写过程中不断进行。因为系统中的类之间往往都存在较多的关联关系，当更改了类的功能时，往往会有多个类受到直接或间接的影响。所以你应该频繁测试以及早发现这种因功能、调整而引起的Bug，越早发现错误解决它的代价越小。频繁测试也是XP编程的一个重要环节，XP编程总让人觉得他们注重功能实现而忽视测试，其实他们也非常关注测试，毕竟测试可以使他们尽可能快的稳步前进。　　自动测试，是指应用一定的测试框架，为每个业务类编写独立的测试用例，类代码调整后，对应的测试用例同步调整。多个测试用例组成一个测试套件一起批量运行，它们就像一个强大的Bug嗅探器，一旦发现Bug就会输出特定的信息报告错误，只要一个测试用例没有通过测试就说明程序中有问题。测试用例中所包含的测试规则完全由你定制，这个测试套件对Bug嗅探的"灵敏度"完全取决于测试用例的测试规则，框架提供编写和运行测试用例的规范性方法。　　在编写一个业务类时，需要相应编写对应的测试用例，一开始挺招"惯性定律"抵触的，因为它要求你将创建一个测试用例类，似乎需要更多的工作。但你的付出是会得到加倍回报的，随着软件类规模的增大你会发现，当传统测试方法越来越捉襟见肘，穷于应付时，基于测试框架的测试技术依然"谈笑自如"。

应该在有可能引入错误的地方引入测试单元，通常这些地方存在于有特定边界条件、复杂算法以及需求变动比较频繁的代码逻辑中。除了这些特性需要被编写成独立的测试单元外，还有一些边界条件比较复杂的对象方法也应该被编写成独立的测试单元。

测试单元应该以一个对象的内部状态的转换为基本编写单元。不但需要保证类的静态约束符合我们的设计意图，而且需要保证对象在特定的条件下的运行状态符合我们的预先设定。