Question

在命名测试方法时，我遵循Roy Osherove的“单元测试艺术”一书中指定的技术 - MethodName_Scenario_Expectation 。它非常适合我的“单位”测试。但是，对于我在'controller'或'coordinator'类中编写的测试，我不一定要测试一种方法。

对于这些测试，我生成了构成一个场景的多个条件，然后我验证了期望。例如，我可以在不同的实例上设置一些属性，生成一个事件，然后验证我对控制器/协调器的期望是否得到满足。现在，我的控制器使用私有事件处理程序处理事件。在这里我的场景是，我设置了一些属性，比如说3

condition1，condition2和condition3

另外，我的方案包括

引发了一个事件

我没有方法名称，因为我的事件处理程序是私有的。我如何命名这样的测试方法？

Answer 1

在这种情况下，我会使用几个测试和不同的命名约定：

将测试类命名为ClassName_Scenario（因此对于同一个类，您将拥有多个测试类）
将测试方法命名为Expectation1，Expectation2，Expectation3 ...

此外，不是在每个测试方法中初始化上下文，而是在[SetUp]方法中初始化

所以你会有这样的事情：

[TestFixture]
public class ClassName_WhenScenarioX
{
     [SetUp]
     void InitContextForScenarioX()
     {
     }

     [Test]
     void ShouldDoY()
     {
         Assert.That(...)
     }

     [Test]
     void ShouldRaiseEventZ()
     {
         Assert.That(...)
     }
}

请注意，只有在断言的执行顺序不重要时才会起作用（每个测试都是独立的，即使它们都依赖于相同的初始上下文）

Answer 2

我倾向于使用几乎完整的句子来描述测试类应该实际提供的内容。这种方式单元测试几乎是该类的文档。我倾向于避免在测试名称中添加技术细节，因为（1）这些都在测试的内容中（2）有人可能会更改测试的内容而不是名称。

示例：

[TestFixture]
public class ClassNameTests
{
     [SetUp]
     void BeforeEveryTest()
     {
     }

     [Test]
     void ParsesCsvStringsToLists()
     {
         Assert.That(...)
     }

     [Test]
     void ThrowsMyExceptionWhenInputStringIsMalformed()
     {
         Assert.That(...)
     }
}

Answer 3

我通常在场景之后命名我的测试方法（如果需要，还有其子类），但我很少在测试名称中包含方法名称或期望值。

对我而言，场景是最重要的，这是代码中并不总是显而易见的，因为它在比代码更高的抽象层次上。所以我需要一个很好的描述性测试名称来进行良好的沟通。但是，在代码中可以看到被调用的方法，类似地，断言/注释记录了期望。而且我是KISS原则的忠实粉丝......

我必须补充一点，我正在使用遗留代码，我们的场景和单元测试通常比教科书单元测试更笨重。此外，我们测试的接口相当简单，通常每个类都有一个“执行”方式。

Answer 4

如果condition1，condition2和condition3是业务规则，则在规则之后命名。

我们如何命名我们检查多个条件的测试方法？

4 个答案: