今天Zoom.Quiet在公司内部分享了对Python测试开发的一些感悟，TDD以及一些开源的Python测试的库。由于一直在测试一线奋战，我被做为特邀嘉宾来到现场。由于时间关系，最后我的分享没有进行。我在这里说说对Zoom.Quiet演讲内容的一些感想吧。

　　1. 重点强调了TDD测试先行的做法，以及新需求到来时进行迭代的测试驱动开发过程。

　　感想：“测试先行”的确是TDD的核心，同时，TDD还有其他一些理念，其实也很值得分享，比如：

　　编写完测试案例后，用最小化或最精简的代码，让测试案例刚刚好通过( just enough)。然后再继续补充测试案例，测试案例可能失败，继而再修改代码，让新的测试案例刚刚好通过。之后一直重复这个过程，直到你再也写不出一个测试案例，需要修改你的代码。“just enough code”，我对于这点感触比较深。一方面因为，我们几乎没有可能一次性写出完全正确让所有测试案例都通过的代码，所以必定存在这个迭代的过程。另一方面，能很好的遵循YAGNI(You Are'nt Gonna Need It)，避免了过度的设计。

　　测试案例是最好的注释，同时也是最好的文档。

　　2. 分享了大量Python的开源测试工具或库。

　　感想：知道了很多自己不知道的东西，很有意义。

　　3. “没有测试案例的持续集成不是持续集成”

　　感想：说的太好了。同时也要自我反省一下，一直想将测试案例加入持续构建，一直都没有去做~

　　4. “测试的本质是什么？”

　　感想：记得一本测试的书讲过，测试的本质，就是“想尽一切办法寻找软件的缺陷！”。我觉得也是有道理的，所谓的“保证软件的质量”，并不准确，至少，我可以举一个反例，进行高效的代码审查以及招聘最优秀的程序员，同样也能保证软件的质量，是不是软件测试呢？有人说自动化测试不能发现新的缺陷，只能保证已发现的BUG不再重现。其实，只是我们理解的是保证BUG不重现，归根结底，自动化测试案例一直重复的执行，还是为了找到软件的缺陷，并且，是存在发现新缺陷的可能的。所以，别想了，软件测试就是找BUG，直到你再也找不出来为止。（你找不出来并不意味着没有）。

　　5. “当你的代码需要使用过多的Mock对象进行测试时，意味着你的代码依赖过多，重构它吧”

　　“不可测的代码，是需要使用大量的Mock对象的代码”

　　“减少依赖，减少Mock对象的使用”

　　感想：对于这两个观点，我有一些不同意见。首先，除非你开发的是类似计算素数或是其他单一性很强的代码，你不可能不依赖到文件系统，数据库，以及网络。而一旦你的测试案例依赖于这三样东西，你的测试案例就不再属于单元测试，而是集成测试。除非你只把这部分代码交给集成测试，不然你必然需要使用Mock对象。

　　当然，这里所说的Mock对象也是广义的概念。严格来说，存在诸如：Spy，Fake，Stub，Mock等具有不同意义的东西。虽然只是概念上的理解，在实际测试过程中对测试案例的理解，还是很有意义的。

　　所以，我觉得，最不可测试的代码，因为是连Mock的机会都不给的代码。这样的代码我遇到过很多，特别是C++的代码，我见过的C++程序员，对依赖注入都没什么概念。依赖注入，是为了减少对具体对象的依赖，同时，也提供了更好的可测性。允许使用Mock对象进行模拟。

　　关于Mock的争论其实有很多，我也只是表达一点自己的看法。我也没有那么绝对，过度使用Mock，我也是不推荐的。

　　6. 有人提问：“TDD对可测性的帮助有多大？”

　　我的回答：很大，非常大。当你写过别人代码的测试案例的时候你就会知道，假如一个家伙从来不写测试案例，他的代码测试起来会非常痛苦。假如另一个家伙自己就会写一些测试案例测试自己的代码，在写测试代码的过程中，其实就已经是在不断的重构，使得代码更具可测性的过程。所以，这样的代码的可测性会强很多。

　　除了Zoom.Quiet极力推荐的《Test-driven development》外，我也推荐一本书：《xUnit Test Patterns》。

　　对于我的观点，欢迎大家拍砖~~