我对 TDD 很陌生，所以如果这个问题听起来很愚蠢，请原谅我。 所以，TDD 应该阻止我在我的项目中引入错误/未定义的行为。但是如果我在我的测试中引入这个呢？测试我的测试是否值得甚至理智，或者这只是一个新手问题？
我已经在互联网上搜索过，但找不到任何关于此事的信息。只有一些关于什么是 TDD 的文章。
感谢您的意见。
我 2013 年的文章为什么要信任测试？ 涵盖了这个问题。总结：
你可以把这个过程想象成复式簿记。看到测试失败是来自被测系统 (SUT) 的关于测试的反馈。看到测试通过是来自测试的关于 SUT 的信息。
通常不需要测试你的测试，但确保你的测试在实际测试你的代码时有效是个好主意。这里有一些提示：
编写清晰、简单的测试：保持测试小、集中且易于理解。避免复杂的逻辑，一次只测试一种行为。
使用测试替身：利用模拟、存根和伪造来隔离您正在测试的行为并最大限度地减少依赖性。
持续审查和重构测试：定期审查您的测试，根据需要更新它们，并确保它们随着代码的发展而保持相关性。 通过遵循这些实践，您可以提高测试质量并减少在其中引入错误的可能性，而无需为测试本身编写测试。
确保您的测试未能通过您的构建：您的测试应该在每次构建之前运行，并且它们应该防止您构建损坏的代码。您可以利用“代码覆盖率”来确保您的测试实际上覆盖了代码库中有意义的部分。
比单元测试更喜欢集成测试：通过使用无头浏览器和库（如 Playwright 或 Puppeteer），集成测试可以用很少的代码行覆盖应用程序的广泛行为。这很好，因为 (a) 您的测试不太可能随着代码的更改而更改，并且 (b) 当所有部分连接在一起而不是孤立时，您可以确保您的代码正常工作。
虽然测试测试？别担心。
TDD 不是软件测试的同义词。
TDD 是一种进行软件测试的特定方法。
将（/应该/可能）阻止您在项目中引入错误/未定义行为的是软件测试，无论它是否以 TDD 方式完成。
虽然为测试写测试在理论上是可以想象的，但我从来没有听说过有人偏执到如此程度以至于真的去做这样的事情。这可能会很可怕。测试函数是不返回任何内容的无参数函数，因此您必须首先将它们中的每一个翻转过来才能对其进行测试。
然后当然是你是否应该为测试的测试编写测试的问题。这是一个反问，你不需要回答它。
你不需要去那里。不要去那里。
从红色到绿色的过渡表明测试代码正在响应生产代码的变化。它是测试的测试。
TDD 让我们对这种联系充满信心。如果您对测试有任何疑问，请故意破坏生产代码以查看测试是否可以防止失败的更改。请参阅谁测试测试？如何增加对测试的信心