解读TDD的五大误区

所谓TDD简单地说就是如下两个步骤：确保全部的需求都能被照顾到；在代码不断增长和重构的过程当中，能够检查全部的功能是否正确。本文咱们一块儿来看下关于TDD的五大误区。

TDD（全称Test Driven Development）测试驱动开发，是一种软件开发的流程，其由敏捷的“极限编程”引入。其开发过程是从功能需求的测试用例开始，先添加一个测试用 例，而后运行全部的测试用例看看有没有问题，再实现测试用例所要测试的功能，而后再运行测试用例，查看是否有case失败，而后重构代码，再重复以上步 骤。

其理念主要是确保两件事：

• 确保全部的需求都能被照顾到。
• 在代码不断增长和重构的过程当中，能够检查全部的功能是否正确。

原文做者Adam Bar在拜读了 Bradley Braithwaite的文章后引起了一些思考，对此，他补充了对TDD的一些见解，列举出TDD的五大误区。如下是文章译文： 

1. 即便没有单元测试，也比有单元测试作的差要好。 （It's better to have no unit tests than to have unit tests done badly ）
2. 利用代码测试可以产生许多高效的代码且代码看起来更加可靠、实用。 

1、不要使用Mocking Framework VS.太多测试设置

也许有人会说，这两点很矛盾，由于使用Mocking Framework会致使产生过多的测试设置。这就须要咱们保持一个良好的平衡问题。

测试代码势必会产生一些依赖关系，假若不使用Mocking framework，那么咱们将没法进行单元测试。这一点是确定的。

这里例举有关代码测试和数据库的 例子——咱们一般称之为集成测试、half-arsed测试，这也是测试查询自己惟一可靠的方法。

可是，在大多数状况下，咱们使用stubs，避免使用mocks——二者以前的区别很是重要。Mocks做为一种行为测试工具常被用来执行检查过分使用的自定义测试，同一我的在同一时间编写代码，就如同检查咱们刚刚故意建立的设计同样。 TDD致使大量的Mock和Stub。Test Case并不必定是那么容易的，若是你的Test Case中的Mock多是错的，你须要重写他们。也许你会说，就算是不用TDD，在正常的开发过程当中，咱们的确须要使用Mock和Stub。没错！的确是这样的，不过，记住，咱们是在实现代码后来决定什么地方放一个Mock或Stub，而不是在代码实现前干这个事的。因此，TDD中，Test Case是开发中最重要的环节，Test Case的质量的问题会直接致使软件开发的正确和效率。

 

咱们更加关注的是真实的验证结果（stubs将带给你不少帮助），而不是经过耦合来实现。 没有什么比维持一个测试套件和spaghetti-flavoured mock 装置更糟糕的事了。

2、主张太多元素

在每次测试时主张有一个逻辑是很好的规则。即便它意味着调用几个Assert，但对我来讲，使用任何asserts 都是同等重要。

3、追溯编写测试

大多数TDD的获益方式，从实施前就可进行思考。好比： 写测试须要成本，测试须要维护。

许多开发者认为这不只这是通往幸福的路径，还有关于负面的状况及边界值（boundary values ）。  此外，它还强烈支持KISS和YAGNI原则，这对于长期代码库来讲很是重要。 

我我的比较喜欢使用TDD来配合检测错误报告。经过从新建立失败条件来编写失败的单元测试使得更容易，这将有助于隔离故障，分析根本缘由所在，这每每比在现实生活的状况下重现 bug容易得多。追溯编写测试只适用于集成测试中查找Bug。

4、测试过多代码

这是一条放之四海而皆准的广泛真理。

在利用单元测试核心代码中我看到许多有价值部分。建立这些代码我更多的是根据TDD原则建立而来（尤为是没有产生错误的代码及没有失败的测试）。 

可是我并不把100% 的代码覆盖率做为最终目标，由于这样没有任何意义。

我想，总会有至关多的代码不仅是适用于单元测试，即协调/组织类型的代码（咱们称之为组成节点将其做为组成root的引用），它们须要一些依赖关系，经过调用几种方法，把代码从这里移植到那里，无需添加任何逻辑，而无需真正干扰数据。

因为其沉重的mocks和stubs 的使用，这种编写测试的代码比代码自己要复杂的多。Bradley的经验法则对我来讲：为每个IF， And，Or，Case，For，While条件语句编写一个单独的测试，当全部分支/条件语句被覆盖时，该代码将会被彻底覆盖。

5、TDD跟测试的关系 

测试是TDD的必然结果。若是团队一直在实践TDD，全部的代码都会有相应的测试，全部的测试其实就是整个系统的脚手架。 TDD方式的开发是从写测试开始的。

使用TDD时，功能开发老是实现沟通结束条件，也就是在何种状况下，能够认为功能完成，这个结束条件是以测试体现的。

实践TDD时，写代码只有两种目的：1. 让一个失败的测试经过。2. 在不添加新功能（也就是不须要添加新的测试）的前提下，让代码、结构或者测试更加清晰、整洁、易懂。

对于需求来讲，TDD更能引导开发人员作出真正符合需求的东西，不会过渡开发。对于设计来讲，TDD的实践能帮你清理思路，但不能教会你作好的设计。对于质量来讲，TDD保证全部的代码都有测试覆盖，确定能提升质量。 

 

写在最后：

对此，有专家建议想要用TDD请首先学会测试的基本功，另外要养成没有测试过的功能坚定不算结束的功能的习惯，这个习惯很重要。为何TDD狂热者可以report出极少数量的bug的缘由之一，就是养成常常性测试的习惯。

 

使用 TDD 的目的是高效的开发高品质的程序。若是发现 TDD 危及这个目标（没有完美的开发模式，TDD也有自身的弱点和局限），那么请适当的妥协。（编译/Rnifeasy）