认识达内从这里开始

在软件测试领域，无论除了需要知道自动化测试以外，同时还需要了解关于单元测试以及测试驱动开发之间的区别，下面我们就一起来了解一下具体内容吧。

这个测试分了几步而且这些步骤都在运行，但是在测试的结尾应该检查些什么东西的，然而并没有检查。

这个所谓的“测试” 其实并没有在测试任何东西。

然后我打开了另外的测试。

更糟糕了。

那个能够在某种程度上测试一些东西的断言语句却被注释掉了。

哇，那确实是让一个测试通过的不错的方法，仅仅将使它失败的代码注释掉就好了。

我接着去检查了各个测试。

没有一个能够测试什么东西。

三千个测试全部都是毫无用处的。

写单元测试跟理解单元测试，以及测试驱动开发是有很大不同的。

什么是单元测试?

单元测试的基本思想是编写可以执行小“单元”代码的测试。

单元测试通常跟要测的源代码使用同一种编程语言，并且会直接使用到源代码。

可以将单元测试看作是测试其它代码的代码。

当我使用“测试”这个字眼的时候，我是指相当宽松的含义，因为单元测试实际上不是测试。它们并不能测试任何东西。

我的意思是说，当你运行一个单元测试时，通常情况下你并不能发现某些代码没法工作。

只有在你写一个单元测试的时候，你才能发现它们没法工作。

是的，代码以后可能会变化，会导致测试失败，所以这个意义上来说，单元测试就是一个回归测试。然而，一般来说，单元测试并不像普通的测试那样，通过执行几个步骤，就能观察该软件是否正常运行。

作为一个编写单元测试的开发人员来说，你可以在写单元测试时发现代码是否按你所预想的方式工作， 因为你会不断地修改代码，直到单元测试通过。

为什么你会编写一个单元测试却不能确保该单元测试可通过?

当你按照这种方式思考时，单元测试更多的是在极低的层次上为特定代码单元指定绝对要求。

你可以把单元测试看成绝对规范。

单元测试指定了：在这些条件下给定一系列输入，这些就是我必须从这个代码单元获得的输出。

真正的单元测试可以测试小的内聚代码单元，在大多数编程语言中 —— 至少是面向对象的语言中 - 是一个类。

什么有时会被称为单元测试?

单元测试和集成测试经常被混淆在一起.

一些所谓的“单元测试”会测试多个类或测试更大的代码单元。

许多开发人员会争辩说，这些仍然是单元测试，因为它们是在低的层次上用代码编写的白盒测试。

你不该和这些人争论。

只要记住这些是集成测试，真正的单元测试测试的是被隔离的小代码单元。

单元测试能创建一组自动化的回归测试，这些测试可以作为软件低层次行为的规范来操作。

这是什么意思?

当你修改垃圾代码时，你就不会破坏它。

这样，单元测试就是测试：回归测试。

但是单元测试的目的不仅仅是构建这些回归测试。

在现实世界中，很少有回归错误能被单元测试捕获，因为更改您正在测试的代码单元几乎总是涉及更改单元测试本身。

测试驱动开发颠倒了业务代码和测试代码的顺序，比如，之前我们是先写业务代码，然后再写单元测试代码对其进行测试(当然也不总是这样). 现在我们必须先写好单元测试代码，然后再写业务代码以通过单元测试。

通过这种方法，单元测试好像正在"驱动"业务代码的开发.

这个流程不断地一遍一遍地重复做下去。

你写了另一个测试代码，它定义了业务代码可能要完成的更多功能。

然后你再修改业务代码或添加一些代码使它可以通过单元测试。

终，你重构了业务代码---或者梳理了代码---使它变得更简洁了。

这个流程经常被叫做“红灯，绿灯，重构完成”。因为在一开始，单元测试肯定会失败(红色)，写好业务代码后，单元测试会成功(绿色)，后代码被重构完成。

测试驱动开发 的目标是什么?

就像单元测试本身可能成为被错用的佳实践一样，测试驱动开发 也可能如此。

做到以下几点很简单：记录你使用 测试驱动开发 做什么，甚至遵循实践规则，并且不理解为什么要这么做或它所提供的价值(如果有的话)。

测试驱动开发 的价值在于测试恰好是完美的规范。

测试驱动开发 本质上是编写明确规范的实践，它能够在编写代码前自动检查。

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。