unit-testing - 可维护的单元测试

Question

我最近使用 TDD 完成了一个项目，我发现这个过程有点像噩梦。我喜欢先写测试，然后看着我的代码增长，但是当需求开始变化并且我开始重构时，我发现我花在重写/修复单元测试上的时间比我写代码的时间要多，实际上要多得多。

当我经历这个过程时，我觉得在应用程序完成后进行测试会容易得多，但如果我这样做了，我将失去 TDD 的所有好处。

那么，编写可维护的 TDD 代码有什么技巧/窍门吗？我目前正在阅读 Roy Osherove 的 The Art Of Unit Testing ，还有其他资源可以帮助我吗？

谢谢

Answer 1

练习

学习如何编写体面的单元测试需要一段时间。一个困难的项目(更像是项目)并不奇怪。

xUnit Test Patterns推荐的书已经很好了，我听说过你正在阅读的书的好消息。

至于一般建议，这取决于您的测试的难点。如果它们经常中断，它们可能不是单元测试，更不是集成测试。如果它们难以设置，SUT(被测系统)可能会显示出过于复杂的迹象，需要进一步模块化。名单还在继续。

我的一些建议是遵循 AAA规则。

安排、行动和断言。每个测试都应该遵循这个公式。这使得测试可读，并且在测试中断时易于维护。

设计仍然很重要

我练习 TDD，但在编写任何代码之前，我会抓起一 block 白板然后乱涂乱画。虽然 TDD 允许您的代码发展，但一些预先设计总是有好处的。然后你至少有一个起点，从这里你的代码可以由你编写的测试驱动。

如果我正在执行一项特别困难的任务，我会制作一个原型(prototype)。忘记 TDD，忘记最佳实践，只写一些代码。显然这不是生产代码，但它提供了一个起点。然后我从这个原型(prototype)考虑实际的系统，以及我需要什么测试。

查看 Google Testing Blog - 这是我开始 TDD 时的转折点。 Misko 的文章(和站点 - 尤其是 Guide to Testable 代码)非常出色，应该为您指明正确的方向。