从单元测试基本概念来看为什么我还是要支持TDD-测试驱动开发

2017-08-25 本文已影响51人仲谋说IT

单元测试就是常说的Unit Test
而TDD其实是uTDD - unit Test Driven Development

unit-test.jpg

在我现在的日常工作中，其中一个很重要职责就是保证新人快速成长。这里的“成长”不是应试教育下的快速成长，更不是通过填鸭式教育、题海战术来达到的成长。而是以理解公司文化的为前提，“素质教育”为基础的健康成长。

我们公司的创始人是《敏捷宣言》提出者之一，哪怕在这样一家敏捷绝对拥趸的科技公司里，也一样会有关于TDD的一些常见问题。我在和新人Pair、带团队和
客户参观的过程中都无一幸免的被问到了如下TDD的问题：

为什么我们要TDD ?
任何时候都要TDD吗？什么情况下不用TDD?
TDD怎么衡量她的价值？实践她的都是开发人员，她到底有没有价值因该开发人员说了算。

这些问题的提出者以及提出时间，总结起来看还挺有意思。有的完全没有接触实践过敏捷；有的相信敏捷，但还没有付之实践；还有的拥抱后坚持实践了一段时间，思考然后，最终提出反问。

有这些问题其实很正常，回答起来也不难。我们大可以把TDD的好处罗列一翻，把一些正确的大道理再叙述一遍，但我们前面可是标榜过我们自己是“素质教育”，我们更希望对一些基础知识认真打磨，让大家根据这些基础知识结合自身的环境，给出自己的判断。学以致用，融汇贯通。

我们这里说的TDD（测试驱动开发），实际上更准确的描述为单元测试驱动开发。先不谈怎么驱动开发，我们一起来掀开单元测试的外衣，看看到底本尊长什么样？怎么就可以驱动开发了？他能解决什么问题？又对什么问题有心无力？

Unit testing is when you write test code to verify units of code.

翻译起来就是：单元测试就是用来验证代码单元正确性所写的测试代码

我们下面站在 先实现后测试 的原生视角来回答几个问题

“单元”到底怎么定义？

在尺寸上并没有清晰的定义。
一小段展现出某些“有用的行为”的代码
一个单元自身通常不表示完整的端对端（end-to-end）行为，它只表示这个端对端行为中的一个子部分。

可以看出这里的“单元”，并没有固定和清晰的定义，比较容易接受的定义是把“单元”和函数划上等号。项目管理中所有的实践，最终都是为了保证项目的按时交付及
质量保证。而且明确说明单元测试不因该表示完整的端对端行为，因为在项目的测试体系里，比如金字塔原理，越接近用户的测试往往是最费时的，所以从成本和质量平衡的角度来看，因该是越精简越好，这其实就是对单元测试提出了明确的要求-集成测试和端到端测试没有覆盖到的，那么单元测试你就给我保证好，至于你用函数分还是以行为分，没有统一的标准。这里借助绝对正确的一句废话-对项目合适的才是最好的。

何时、何故需要写单元测试？

你刚刚完成了一个特性（Feature）的编码并且想确保它能够按照预期工作。
你想用文档记录一个代码中的修改，以便你或其他人能够在以后明白相关的意图。
你需要修改代码，同时希望确保这些即将来临的修改不会破坏任何已经存在的行为。
你希望了解当前系统中的行为。
你希望知道第三方代码的行为在什么时候会与你的期望不符。

简单来说也就是对测试特性的另一种描述，通常我们可以把测试当成文档，因为单元测试要足够的简单，不然就会有人问这样的问题：我们用什么来保证测试本身的正确性呢？是不是得为我们的测试再写测试呢，显然不是，不然不就死循环了嘛。但这不意味着我们就不用保证测试本身的正确性了，简洁性其实就是这个目的，你一眼就能看出来正确与否，那么我们大家都有信心相信我们测试代码的质量，以及功能模块的稳定性也可以通过测试得到了因有的保障。