过多的设置意味着不佳的模式。你应该只需要设置那些与你正在测试的类直接相关的对象。
尽量让单元测试精细化，这将带来可移植性更强的代码，并将它推向更加清晰、更加独立的实现。
通过回调制针测试
回调制针（backpointer）完全就是个麻烦事，应该避免其出现。它会带来相当多的异常，状态模式就是其中一个。一定要了解自己实现回调指针的理由。如果理由是“它会起作用”，那么你就在失去什么东西。
视图测试——将测试三要素实例化
在一个构造完好的应用程序里，视图层应该从域抽象出来，达到一种不需要创建视图就能够测试该应用程序的程度。不够精细的测试需要更加经常地更改。见上文测试打破常规。
这只是来自一个不断改进的小例子。我再提醒一遍，从简单的开始，保持其基本框架，得到所有人的同意。
连续集成
瀑布式方法的一个缺陷是代码库的集成往往每隔数周或者数月之久才进行一次。新的错误常常会随着代码的集成而不断暴露出来，我们不得不花额外的时间来更正错误并重新集成。如果集成不是频繁进行，那么反馈就不可能像应该的那么紧密。敏捷开发要求进行更加频繁的集成——在3Q的案例里，这意味着每天要集成一到两次。
大多数小组一般都会有一台构建计算机，成对的开发人员能够利用其检查在测试－编码－重整循环里编写好的代码。每对开发人员都有确信其代码在被集成到代码库之前就已经经过测试和重整。一旦检验完毕，自动化的构建计算机就会编译所有的代码，运行所有的测试，并通过显示器（向小组）显示出来——构建过程是否需要引起注意——例如：新加入的代码有没有破坏什么东西？
文章来源于领测软件测试网 https://www.ltesting.net/
