我看TDD测试驱动开发

标签：io   ar   java   on   问题   cti   代码   as   res   

　　今天在实验室给大家介绍了一下TDD和Docker，大家对TDD都比较感兴趣，包括老板，也问了一些问题。

　　还是从头来说TDD吧，TDD作为敏捷开发领域的领头军，充满魅力，同时也充满争议。一切从三大军规说起：

1. 除非这能让失败的单元测试通过，否则不允许去编写任何的产品代码。
2. 只允许编写刚好能够导致失败的单元测试。 （编译失败也属于一种失败）
3. 只允许编写刚好能够导致一个失败的单元测试通过的产品代码。

　　上面这三个是网上找的中文翻译，回来后，我还是决定要把英文原文找出来，相对与上面三句拗口蹩脚的翻译，我相信，下面的英文应该更好阅读，更方便理解一点：

1. You are not allowed to write any production code unless it is to make a failing unit test pass.
2. You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
3. You are not allowed to write any more production code than is sufficient to pass the one failing unit test.

　　从第一条开始说把，这一条限制了我们对代码的修改力度，一般在一个大的项目里面，代码比较庞杂，这里限制修改代码的前提是你的修改能够是失败的单元测试通过，那么至于其他的代码，你就不用去care，也不用去修改。如果没有这个限制的话，你可以随性的在保证单元测试通过的前提下，再额外写一些附加的代码，或者做一些与该失败的单元测试不相关的修改，那么，在大项目里面，很可能会牵一发而动全身，由于你的额外修改，牵扯出其他的问题或者bug。

　　再看第二点,我的理解是军规规定，在编写单元测试的时候，只要有一个单元测试用例没有通过，那么我们就要停下来去修改我们的代码，同时，变异错误也是单元测试失败的一种情况(Java IDE一般会在编译失败的地方标红)。另一种理解，这里强调我们在编写单元测试的时候更多的要关注代码的各种边界条件，而其他一些情况则不应该出现在单元测试里面。后一种理解的层面是在单元测试的层面去理解，说的也是对的，但是把英文原文翻出来，应该第一种理解更合理。

　　关于第三点，和第一点一起，再次约束了代码修改的力度。

　　我也是刚开始接触TDD，挺有意思～～

我看TDD测试驱动开发

标签：io   ar   java   on   问题   cti   代码   as   res   

原文地址：http://www.cnblogs.com/alway6s/p/4117704.html