TDD仅在理论上
一年多以前，我很幸运能够休息9个月。我决定在那段时间里磨练自己的C＃技能。我开始从事许多项目，并强迫自己遵循TDD。 这是一个相当启发的过程。 刚开始时很难，但是随着时间的流逝，我学会了如何编写更多可测试的代码（事实证明，这往往是更多的SOLID代码），并且在此过程中，我还提高了OO设计技巧。 现在，我回到了工作岗位，并且注意到了一些奇怪的事情。 我宁愿不遵循TDD。 我发现TDD会使我慢下来，实际上使设计干净的应用程序更加困难。 相反，我采用了一种（完全）不同的方法： 挑选垂直的作品 开发功能正常的原型 重构直到一切都变得整洁 请欣赏一下我编写的精美的SOLID和可测试的代码。 您可能已经注意到，第1步不是“定义我的测试目标的公开表面”，而第2步不是“在所述公开表面上测试耶稣”。您可能还注意到，所有步骤都不涉及测试。我正在编写可测试的代码，但是我尚未对其进行测试。 现在，我想说明一下，我实际上并没有进行任何类型的测试。我正在编写的代码有效。它有效，因为我正在手动测试它。 我还想明确指出，我也没有提到所有自动化测试。这是我的过程与众不同的地方。这就是为什么我问这个问题。 TDD理论上。不在实践中。 我的过程有所发展，我在TDD和没有发现我认为非常有效且也相当安全的测试之间取得了平衡。内容如下： 在考虑到测试的情况下实现工作的垂直工作，但是不要编写任何测试。 如果在路上（例如，一个月后），该切片需要修改 编写单元测试，集成测试，行为测试等，以确保工作片段正确无误 修改代码 如果该切片不需要修改， 没做什么 通过简单地将编写测试的负担从编写代码之前转移到修改代码之前，我已经能够生产出更多的工作代码。而且，当我确实着手编写测试时，我编写的测试数量要少得多，但是覆盖的范围却差不多（投资回报率更高）。 我喜欢这个过程，但是我担心它可能无法很好地扩展。它的成功取决于开发人员在更改测试之前勤于编写测试。这似乎是一个很大的风险。但是，TDD具有相同的风险。 那么，我该死[BT] DD，还是这是一种实用的编码和测试的常见形式？ 我想继续这样工作。从长远来看，我该怎么做才能使该过程正常运行？ 注意： 我是项目的唯一开发人员，我负责所有工作：需求收集，设计，架构，测试，部署等。我怀疑这就是我的流程正常运行的原因。