我已经 4 个月进入专业软件开发领域。 TDD 在我的公司 GO-JEK 是不可协商的。 以下是我的观察：人们倾向于先写代码，然后为它写测试。显然，这对于有 4-5 年软件开发经验且之前没有遵循 TDD 的人来说更方便. 那么，人们首先编写一个失败的测试，然后编写代码来通过它的原因是什么？为什么人们不先编写代码然后为其添加测试？ 我们可以通过任何一种方式进行重构
【问题讨论】：
标签： unit-testing tdd automated-tests software-design
这是个好问题。既然我们最终希望我们的测试通过，为什么不首先编写它们让它们通过呢？
答案是我们真的希望我们的测试能够推动开发。我们希望测试首先出现。因为当我们编写需要某些功能的测试时，这是对所需内容的具体表达，并且新的功能已经定义好。最初该功能不存在（因此测试为红色）；当我们成功添加功能时，测试是绿色的。这是一个明确的决定：要么功能存在且测试通过 - 要么不存在且测试失败。
如果我们把测试写成绿色（功能已经存在），我们写的功能可能比我们实际需要的多。或者我们可能编写了错误的代码——功能存在但错误——以及相应的错误测试。当我们首先编写测试时，我们见证了代码库从缺乏必要功能的状态转变为拥有它的状态——我们非常有信心地知道我们做对了。
【讨论】：
通过编写失败的测试，您知道您的测试可能失败，这是单元测试的重点，在不工作时会失败。有可能只看到测试通过，就可以用永远不会失败的方式编写它，即忘记添加断言或编写不佳的测试。
此外，通过逐步通过“失败”测试，您知道每次代码更改都会增加价值。
【讨论】：
我的首选方法是编写测试，然后编写代码以使其通过 (TDD)，但即使您最终为现有代码编写测试（例如使用遗留代码），您仍然希望执行 RED -绿色 - 重构过程。
为现有代码编写一个您认为会失败的测试（例如通过反转您的断言），然后验证它确实失败，事实上，失败会让您确信您的测试正常工作以及何时设置断言在正确的意义上，它会令人信服地通过。否则，你怎么知道你没有从测试中得到误报 - 或者测试实际上是由测试运行器运行的（使用一些单元测试框架）？
【讨论】：