使用单元测试编程工作流但没有TDD

Question

我一直认为，当你进行单元测试时，你必须做TDD。然而，经过几个月的阅读后，事实证明并非如此。标准TDD工作流程首先像写入测试，然后编写代码以满足您的测试，然后迭代。

问题是，我似乎无法想象如何进行单元测试但不遵循TDD工作流程。你知道我能做到这一点吗？

Answer 1

在没有TDD的情况下进行单元测试可以像编写一些方法一样简单，然后编写一些单元测试来证明它们能够按照您的想法进行操作。一旦测试到位，您可以选择重构代码以改进实现，安全地知道如果您引入任何错误，测试应该捕获它们。或者，您可以编写所有代码，然后编写所有测试，但这样做的缺点是，如果某些测试中断了，那么自编写代码以来可能已经很久了，因此查找和修复问题会更难。

TDD有一个三阶段循环：红色（写入测试失败），绿色（编写使测试通过所需的代码）和重构（积极重构代码以改进代码设计）。

TDD的一些优点是，通过首先编写测试，你可以证明它们可能会失败（否则你可能会意外地编写一个总是会通过的测试）并且你正在编写与你如何无关的测试。重新编写代码（这样你就不太可能编写包含与生产代码相同逻辑的测试 - 这是没有意义的。）

Answer 2

TDD首先首先进行小的设计步骤，例如考虑你的“所需”方法签名，然后为它编写测试，然后将其实现到绿色，然后在必要时进行重构。

这个工作流程对我来说很有意义。

或者，您可以在之后编写测试以“证明”一些信心。但是你缺少小的设计步骤，然后是新兴的方面，通过设计，实现绿色，重构，你的设计/实现正在出现，同时你有你的测试来证明正确的行为。

这些是我的想法，但如果您觉得这不适合您的问题，那么请更具体地说明您的需求。