之前的一篇文章中，我们讨论了3P书中保龄球程序，文章的最后我提出了一个问题：
代码可以通过单元测试进行验证,那么单元测试应该如何验证?或者说我们如何保证写出正确的单元测试呢?
就这个问题，我采访了一些TW的同事，把他们的答案总结了一下，本想在去印度之前发出来，结果一拖再拖。等回到北京之后，发现我做记录的本子找不见了，丢失了重要的资料，不应该呀。（下次应该随时发到网上，或者保存一份电子版）
总之下面的观点是我凭借会议和一些简单的记录总结的，欢迎大家提意见。（话说最近正在读Kent beck经典的TDD，我倒想看看他老人家对这个问题有什么高见）
问题：我们如何保证写出正确的(好的)单元测试呢?
TA说：
要测试的类要有高内聚，低耦合的特性
测试需要相对独立
不要使用mock来模仿，要能真实的反映代码中的逻辑
测试要有高的覆盖率
一旦更改关键逻辑，之前通过的测试一定要失败
TA说：
在进行开发前，story应该建立task，在task里面就已经有初步设计方案
一个case应该尽量简单，不要有过多的职责
严格按照TDD模式进行开发，红绿交替
TA说：
要能真实的反映类的内部情况，验证语句要仔细
尽量独立
从大的测试推导出小测试
TA说：
没有无bug的程序，就算100%测试覆盖率也无法避免
坚持TDD原则
尽量多留心边缘情况
最后推荐一篇文章，TDD的实用主义。读完这篇文章后，我想你会对TDD中的原则有更多的理解吧。