unit-testing - 进行测试驱动开发之前的注意事项

Question

我开始使用 JavaScript 的测试驱动开发，但我想开始在我的不同项目中使用它。

我想知道典型的错误是什么以及如何避免它们？

另外，我想知道我应该阅读什么以使测试驱动开发更容易学习和应用于我的代码。

提前致谢。

Answer 1

我在使用 TDD 时遇到的最大问题是开发人员对单元测试没有信心。糟糕的单元测试浪费的时间多于节省的时间。困惑的、不可信的、不可维护的、不可读的测试很快就被淘汰了，厌倦的开发人员需要时间想要再次自动进行单元测试。

Per Fagrell 提出了一些很好的观点，尤其是在每次更改后运行测试方面；在任何测试更改之前和之后运行测试应该成为第二天性。

框架:

将 QUnit 视为您的 JS 测试框架:http://docs.jquery.com/Qunit

我有一个带有依赖标记的测试工具页面，并且测试在页面加载时运行得非常好。

你可以按照

安排

法

断言

使用 QUnit 进行单元测试的流程。

但是，您必须手动实现测试设置和拆卸方法并在测试方法中调用它们。这些将有助于通过保持所有测试的条件相同来隔离测试用例，并防止测试依赖于它们的运行顺序。

在您将使用的其他语言中寻找有用的框架。 NUnit在.NET 中非常流行。

隔离:

Per Fagrell 也对隔离提出了一个很好的观点。在开始测试之前，应该彻底理解单元测试(测试功能原子的一个方面)和集成(测试多个原子如何协同工作)之间的区别。如果您在测试方法中有多个断言，则您不是单元测试，需要更改您的测试方法。

约定:

来自优秀的 The Art Of Unit Testing 的良好命名约定你的测试是 MethodUnderTest_Condition_ExpectedBehaviour 例如

Expand_TextVariable_ExpandsText

来自 the same book保持你的测试:

值得信赖

可维护

可读

否则，您和其他开发人员将不会费心运行测试。

假货:

一个常见的误解是两种假货的区别: stub 和 模拟 .

一个 接缝通过将代码所依赖的功能抽象到接口(interface)中，在代码中创建。例如。 Controller 不依赖于具体的存储库，它将依赖于 IRepository。

一个 stub 然后实现这个 IRepository 并返回伪造的值；它用于隔离 Controller 代码以隔离运行。例如 GetCustomer()将创建一个新客户并将其返回，而无需调用真正的存储库或任何商店。 从未针对 测试 stub .
一个 模拟 就像一个 stub ，除了它可以保存可以测试的值。例如 AddCustomer(Customer customerToBeAdded) ，您的模拟将接受该值并可以断言。 模拟可以针对 进行测试.

看看一个测试隔离框架(或模拟框架)，它可以为给定的接口(interface)自动创建假货。

对 mock 用途的误解导致不止一个开发人员创建了一个 mock 来测试功能，然后针对 mock 本身编写测试。

资源:

我提到了 The Art Of Unit Testing我彻底推荐它。这是一本书，连同 Code Complete，如果办公室着火了，我会去拿。

希望有帮助。