测试驱动开发 测试前移_测试驱动学科

测试驱动开发 测试前移

随着“ TDD是死还是生”的继续，有趣的是看到了不同类型的讨论。 这是一个例子：

TDD评论家的新默认答案：您怎么知道？

— Darren Cauthon（@darrencauthon） 2014年5月5日

那里的双向对话不多。

与上述推文相反，对TDD感到失望的人实际上已经使用了它。 也许是来信，也许不是。 事实是，他们认为TDD让他们失望了。

我知道为什么

这是最近的故事。

最近，我们使用6年的代码基础，希望添加一些新功能。 我们已经决定将TDD用于新组件，然后将它们嵌入到代码库中。 我们已经预先编写了新的集成测试。

到目前为止，一切都很好。 首先进行按书考试。

我们想要使用TDD，因为：

1. 1. 涉及很多内部逻辑，我们要确保它是正确的
   2. 我们不确定什么是正确的设计
   3. 在当前实现之外开发新功能可为我们提供更好的控制和更快的反馈。

我的搭档对TDD还是陌生的，我们已经为此配对了几天，从一个班级转移到另一个班级，添加测试并看到它们通过。

在短短的几天里，我遇到了两种挣扎。

第一个在我们两个之间。 我要求增加步骤，测试代码重构，不要急于前进。 换句话说，约束我的伴侣。

我可以看到它是如何折磨他的。 不断发展的设计让人感激不已，但更多的时刻是“我会坚持下去，但不是为了好玩”。 确实，在第二天结束时，我们分裂了，第二天又重新加入了。 他在现有代码库中添加了一些代码，没有进行测试，也不属于新设计的一部分。

第二个是内部的-随着工作的继续，我们添加了越来越多的测试，几次更改了设计，重命名并提取了设计。 TDD附带的所有好东西。 可是，我的脑海里却一直传来一点声音。 它说：“所有这些工作都可以在几个小时内完成，您为此任务做得太多了”。

这是两天工作的结果。 您认为几个月的项目需要多少努力？ 每个人都能度过难关吗？

TDD是一门学科

我通常将TDD解释为一种方法，然后在两个词的意义上都将其解释为一门学科。 使用TDD需要纪律和信心，而不是屈服于黑暗面。 可能并不总是那么黑暗。 或可能看起来不像。

TDD发誓的人已经发展了这门学科，并掌握了使它起作用并避免很多漏洞的许多技能。

许多人已经征服了他们的脑袋。 但我敢打赌，它仍然存在。

失望的人无法做到这一点。 容易说“他们不理解”，“他们没有四处寻找价值”或“您怎么知道”。

我认为失望来自未兑现的承诺：我们将TDD描述为简单的，仅需遵循几个步骤。

没有人会谈论具有不同技能的人之间不断的斗争，快速完成任务的压力以及所有这些问题：没有妥协，或者您做错了。

这就是全部道理：坚持下去，您将获得回报。

但是请知道：TDD是艰苦的工作。

希望您不会失望。

翻译自: https://www.javacodegeeks.com/2014/05/test-driven-discipline.html

测试驱动开发 测试前移