b40属于fdd还是tdd_TDD –刹车开还是关？

b40属于fdd还是tdd

最初发布在LinkedIn上的内容是“没有TDD的生活” –踩刹车还是不踩刹车？

这个版本已根据我目前对TDD的思考和编写方式进行了更新！

很久以前…

今天，我们的单元测试之一失败了。它的失败使我们的自动发布流程停滞不前，我们花了一些时间来解决问题。

失败的原因是软件版本号意外更改。尽管测试是在检查是否有任何“版本号成形”的东西，而不是特定版本的检查-一种明智的方法，但它仍然失败。简而言之，我们进行的有意更改因不符合要求的测试而延迟。

因此，我们花了很多精力编写一个单元测试，然后这种测试使我们无法做完全正确的事情。这会使TDD失效吗？如果您不能进行更改，那是否等同于踩刹车？如果这样做会使TDD放慢速度，TDD不好吗？

进行测试没错。该软件发布其版本号的方式存在一个错误，并且专门进行了测试以确保它不会再次出现。当测试失败时，我们知道唯一需要担心的是版本号。

我们也知道我们想要发布的功能仍然可以使用，即使没有旋转应用程序来用手指和眼睛对其进行测试。实际上，感谢TDD，我们根本不需要手动对其进行测试。

就修复测试中的中断而言，错误是立即清除的，我们只需要在正则表达式中添加几个* s即可。烦人的和更多的等待时间，但是没什么大不了的。

那么测试是自己付出还是付出成本？也许在这种情况下，这是大约10分钟的净成本。也许我们不需要手动测试该功能（可能需要先运行几次该软件才可以使用）的事实已经使TDD变成了巨大的净收益。从这单个事件很难衡量。

但是，此测试的兄弟姐妹仍在努力保护代码库以防意外更改。

当天晚些时候，另一项更改使我们的应用程序无法在Tomcat上启动。我知道–哪一天！我们从来没有尝试过将失败的构建升级到实际环境，自动化的端到端测试发现了失败，并阻止了我们推广变更。

测试真正阻止了不良行为的发生，因为它们可以破坏管道中可能造成损害的各个阶段，这才是真正的好处。

当然，偶尔会刹车，但释放火车并不是失控的火车！

编写测试会花费一些时间，但是它们通过阻止您运行环境来检查最简单的事情而获得回报。当将测试集成到您的构建中时，它将阻止您破坏更高的环境。

最后，尝试构建测试的原则经常导致找到更简单的解决方案和设计更简洁的界面。

当然，您可以轻易地辩称，使您减速的多余东西既超出了需求，又不利于快速发展……但是要辩称，对于TDD来说，将TDD定义为您不应该编写的那种测试-即需要付出的努力时间长，并且您必须花费太长时间进行维护。那是稻草人的论点。

找到实际的中间立场是一门艺术和一种平衡的行为。需要不断审查的一种。

翻译自: https://www.javacodegeeks.com/2020/04/tdd-brakes-on-or-off.html

b40属于fdd还是tdd