TDD 一般是开发人员首先编写单元测试设计的代码。开发人员和 QA 人员处理测试概念的方式存在根本差异。将单元测试视为代码合同更有帮助。这些将随着时间的推移而更新和更改，这是主要区别。对于 QA 人员来说，测试一旦起作用，就应该始终起作用，除非该功能已被明确删除。对于开发人员来说，只要修改了它们所涵盖的代码，就会更新/修改单元测试。这并不意味着单元测试毫无用处。它们非常适合测试业务规则，也非常适合告知开发人员给定方法做什么或应该做什么。单元测试通常会在发现涉及不同区域之间交互的错误时分解。测试文档通常是测试方法的大纲和要涵盖的领域。然后创建一个包含测试步骤的测试计划。单元测试应该与每个构建一起运行，以便它们服务于任何实际目的。成功运行后，应对测试计划进行自动化审查。通常，您最初假设需要测试的东西并不是随着时间的推移而需要的。我认为诀窍是为给定的功能制定一个好的测试计划，然后在功能完成后配对完成测试用例，将该功能的“核心”测试用例添加到回归中。

真正意义上的 TDD 与 Aruna 所描述的完全一样。开发人员编写自动化单元测试，观察测试失败，然后继续编写单元测试要测试的代码，编写代码直到它通过，然后重构，同时维护核心单元测试。

理想情况下（至少在我的世界里），所有的测试也应该在一个测试运行器中组织成套件，比如 JUnit（没有使用 Java 的经验，但是，我似乎记得你说过你在公司使用过 Java）。这样，您还可以随时查看您的更改是否会在您测试过的任何先前代码中产生错误，然后再将其交给测试。

我看不到真正的危险信号（也与流感和发烧作斗争，所以我可能是错的），但是，如果您要查看 JUnit 或任何其他 xUnit，您认为您可以编写快速测试来进行测试吗？你的每一种方法？你真的认为这需要更长的时间吗？对于单元测试和一般的 TDD，通常不需要大量的框架。如果您每天只需要多花半小时到一个小时来编写测试，并且您自己的输出最终会更加可靠并且符合客户的规格，那么您的经理会介意吗？

根据您的编辑进行编辑： 在我自己的想法中，虽然可能不一定在其他人的想法中，但 TDD 是自动化的。在编写代码后手动测试代码只是一个好习惯。但是，如果您确实想采用 TDD 的动作并将它们应用到手册中，您可能会立即看到代码的一些改进。

1. 准确写下您希望代码执行的操作
2. 编写代码
3. 断言代码完全按预期运行。

积极的一面是，您能够将这些测试提供给变革拥护者。

不利的一面是，如果您想确保它在未来仍能按预期工作，则必须手动进行。

我一直从事测试驱动开发，这就是我们接近它的方式。开发人员甚至在开始编码之前就开发了自动化单元测试。假设有 18 个测试来验证付款方式。在他编写代码之前，所有 18 个测试都会失败。编码完成后，他将确保所有 18 个自动化单元测试都通过。完成单元测试后，他会将测试移交给 QA。

我们在公司进行了自动化单元测试。我不确定是否必须将其自动化。

TDD 都不是手动测试。“驱动”部分的整个想法是，每次更改源代码时都会运行一组测试，以保持稳定性并防止出现回归问题。

然而，测试并不需要是单元测试。如果您愿意，它们可以是例如自动化 UI 测试。