我进入专业软件开发已有4个月。 TDD在我公司GO-JEK是不可谈判的。 以下是我的观察结果：人们倾向于首先编写代码，然后为其编写测试。显然，这对于具有4 - 5年s / w开发经验且不遵循TDD的人来说更方便。 那么，人们首先编写失败的测试，然后编写代码来传递它的原因是什么？为什么人们不首先编写代码然后为它添加测试？ 我们可以用任何方式进行重构
答案 0 :(得分：11)
这是一个很好的问题。既然我们最终希望我们的测试通过，为什么不写它们以便它们首先传递？
答案是我们真的希望我们的测试是驱动开发。我们希望测试首先出现。因为当我们编写需要某些功能的测试时，这是所需内容的具体表达，并且新功能的定义很明确。最初该功能不存在（因此测试为红色）;当我们成功添加功能时，测试为绿色。这是一个干净的决心：功能是否存在且测试正在通过 - 或者不是，测试失败。
如果我们编写测试绿色（已经存在功能），我们可能编写了比实际需要更多的功能。或者我们可能编写了错误的代码 - 功能存在但错误 - 以及相应的错误测试。当我们首先编写测试时，我们会看到代码库从缺乏必要功能的状态转变为拥有它 - 并且我们非常自信地知道我们已经做对了。
答案 1 :(得分：1)
通过编写失败的测试，您知道您的测试可能失败，这是单元测试的重点，在不工作时失败。只有看到测试通过才有可能，它可以以永不失败的方式编写，即忘记添加断言或写得不好的测试。
同样通过逐渐通过＆＃39;失败＆＃39;测试，您知道每次代码更改都会增加价值。
答案 2 :(得分：0)
我首选的方法是编写测试，然后编写代码使其通过（TDD），但即使你最终编写现有代码的测试（例如使用遗留代码），你仍然想要做RED - 绿色 - 重构过程。
编写一个您认为现有代码失败的测试（例如通过反转断言），然后验证它确实失败了，实际上，失败将使您确信测试工作正常以及何时设置断言从正确的意义上说，它会令人信服地通过。否则，你怎么知道你没有从测试中得到误报 - 或者测试实际上是由测试运行器运行（带有一些单元测试框架）？