我看过很多关于为什么测试驱动开发是好的文章以及它减少了开发时间等等。但是在搜索了很多论坛之后，我仍然没有得到 TDD 的具体优势。我并不是说测试是一件坏事，但我的观点是，如果我在编写源代码之后编写单元测试而不是像 TDD 建议的那样进行反之，会有什么危害。一旦完成，这两个测试用例确实像回归测试一样。在尝试在遗留代码中遵循 TDD 时，我也遇到了很多问题。我猜现在大部分代码都是遗留代码，我们必须在没有预先存在的测试的情况下修改代码。 TDD 也仅限于单元测试，甚至系统级和集成测试。我只是无法想象我们如何在不编写源代码的情况下进行集成测试。
最佳答案
让我通过问一个修辞问题来回答:
如果您要编写软件，难道您不会从收集和写下软件的需求开始吗？
TDD 的基本原则意味着您的测试用例 是 你的要求。因此，通过先写下您的测试，您首先要写下您的需求。你只是以不同的方式去做。
现在这是做事的最佳方式吗？那是主观的。但这本质上就是 TDD 首先编写测试的原因。
关于unit-testing - 在编写源代码之前或之后进行 TDD 和测试？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2060861/