Unit testing 为具有多个执行路径的函数编写测试的TDD过程

在进行测试驱动开发时，我遇到了一个需要编写的函数，该函数类似于以下内容：

public MyClass DoSomething(string value)
{
    SomeClass existCheck = repository.Get(value);

    if(existCheck == null)
        throw new InvalidOperationException("SomeClass must exist to do something");

    if(existCheck.MyClass != null)
        return existCheck.MyClass;

    MyClass myClass = new MyClass()
    {
        // create object
    };

    return myClass;
}

使用TDD，我需要编写单独的测试

断言抛出了异常 断言返回现有的SomeClass 断言返回了一个新的MyClass

---

我是先编写所有三个测试，然后编写它们，还是先编写每个测试，然后在测试通过所需的函数中编写功能，然后编写下一个测试，然后编写功能代码等？

为每个预期行为编写单独的测试

一个好的经验法则是每个测试通常应该包含一个断言

编辑-回答实际提出的问题

TDD过程是编写每个测试，使其通过，然后重构您所做的。只有在完成之后，才能继续编写下一个测试

---

从技术上讲，您可以提前编写其他测试，但要注释掉它们，所以就好像它们还没有编写过一样。不过，在未来的测试上花很少的时间，因为根据您在第一次通过测试时所做的工作，然后再进行重构，您可能会发现这些测试是错误的。

TDD的基本工作流程是红色/绿色/重构：

首先写测试，它应该失败

编写尽可能少的生产代码，并尽可能简单地使测试通过

重构生产代码，保持绿色状态

如果您发现并非所有内容都已实现，请从第1点开始。因此，在您的情况下，您可以先编写所有测试，然后实现所有内容，或者为第一个分支编写测试，通过编写第一个条件使其变为绿色，为第二个分支编写测试，使其通过，等等

---

在我看来，在开始实际代码之前，最好有一个完整的问题描述和完整的测试套件，而不是在测试和生产代码之间来回切换。

我一直认为，对于TDD，你应该采取小步骤，采用红灯-绿灯的方法。我将采取以下步骤：

为existCheck==null场景编写一个测试，该场景将在红灯时失败 完成场景1成功所需的工作，并重新运行测试绿灯 为existCheck.MyClass！编写第二个测试空场景，将失败。通常可以通过复制第一个测试并修改它来实现这一点。 修改方法，使测试1和2都通过。 对最终执行路径重复步骤3和4。

---

通常，我发现您可以在方法进行时进行测试，然后在每次到达分支时复制测试，根据不同的路径调整每个测试。

这取决于您的攻角。如果你已经弄清了类的整个模式——你的问题表明了这一点——那么你就编写了所有的测试。如果您的代码以较小的步骤发展，那么您将在那时进行测试。TDD的关键是首先编写测试

这就是我打算做的，我的问题是，我是写第一个测试，然后对功能进行编码使其通过，然后写第二个测试，然后对功能进行编码，还是写所有三个测试，然后对所有测试的功能进行编码？更新了我的问题。我刚刚注意到有一个类似的问题。看见