•  22-10-2019
  •  | 
  •  

题

通常，在谈论编码标准时，我们会参考程序本身的代码，但是单元测试呢？是否有某些单位测试独有的编码标准指南？这些是什么？

有帮助吗？

解决方案

在我的头顶上，我可以想到测试代码的编码样式的三个区别。

在命名测试方法中，我遵循 shouldDoSomethingWhenSomeConditionHolds.

在测试中，习惯遵循以下间距模式：

@Test
shouldReturnAccountBalenceWhenGetBalenceIsCalled() {
    // Some lines 
    // of setup code
    // go here.

    // The action being tested happens after a blank line.

    // An assertion follows another blank line.
}

有些人仅坚持每次测试一个主张，但这远非普遍。

与生产代码相比，干燥（不要重复自己）在测试代码中的考虑因素少。虽然应将某些重复的代码放在设置方法或测试工具类中，但在测试代码中争取零重复的努力将导致紧密耦合和不灵活的测试，这会阻止重构。

其他提示

Roy Osherove建议使用以下模式来命名您的测试：

NameOfMethodUnderTest_StateUnderTest_ExpectedBehavior()

看 http://weblogs.asp.net/rosherove/archive/2005/04/03/testnamingstandards.aspx

最主要的是记住，单位测试本质上是微型规范。这意味着重点必须始终放在可读性上。

首先，这意味着名称必须清楚地传达正在测试的内容以及所断言的内容。

其次，有时被遗忘的是，作为规格，他们应该这样做 - 指定行为。也就是说，单元测试不应包含逻辑 - 或可能属于重复程序功能而不是测试程序的陷阱。

有时，测试将涉及要设置复杂的对象，您应该努力使用此类设置与测试分开使用此类设置 对象母亲 或a 测试数据构建器.

我将提出几本书的建议：

Xunit测试模式：重构测试代码： 很棒的书，有人说这有点干，但我不这么认为。有关许多不同的组织测试方式以及如何保持它们可维护的方式，详细介绍了很多细节。相关，如果您使用的是Nunit等。

单元测试的艺术：带有.NET的示例: ：关于写作和维护测试的最佳书籍。尽管确实是新的，但我发现嘲笑部分已经过时了，因为AAA语法现在已经是标准的，而不仅仅是另一种做到这一点的方式。

在测试的指导下，不断发展的面向对象的软件: ：这本书真是太神奇了！到目前为止，最好的单元测试书，也是唯一将单位测试作为一流公民的高级书籍。当它是一个公共测试版时，正在阅读此书，并从那以后推荐。整本书中使用了出色的现实世界工作示例。不过，建议您先阅读罗伊的书。

不要将逻辑放在单元测试中。例如，假设您正在测试一个添加方法，您可以拥有类似的东西：

void MyTest_SaysHello()
{
   string name = "Bob";
   string expected = string.Format("Hello, {0}", name);
   IMyObjectType myObject = new MyObjectType();
   string actual = myObject.SayHello(name);
   Assert.AreEqual(expected, actual);
}

在这种特殊情况下，您可能会重复与测试中的逻辑相同的逻辑，因此您实际上是在测试“ 1 + 1 == 1 + 1”，而不是“ 1 + 1 == 2”，这是“真实”测试。因此，您真正希望测试代码的外观是：

void MyTest_SaysHello()
{
   string expected = "Hello, Bob";
   IMyObjectType myObject = new MyObjectType();
   string actual = myObject.SayHello("Bob");
   Assert.AreEqual(expected, actual);
}

长而描述的方法名称。 请记住，测试方法从未从代码中调用（由单位测试跑者调用，它通过反射发现并调用它们），因此可以疯狂并拥有50-80个字符的方法名称是可以的。只要名称回答三个问题，特定的命名约定（骆驼案，下划线，“应该”，“必须”，“何时”，“给定”等）并不重要。

  • 正在测试什么？
  • 有什么条件？
  • 预期的结果是什么？

测试方法应该很短.

测试方法应具有 简单的线性结构. 。否if或循环构造。

测试方法应遵循 “安排进攻”模式.

每个测试都应 测试一件事. 。这通常意味着每次测试一个断言。类似的测试 { Do A; Assert B; Assert C; } 应该重构为两者： { Do A; Assert B; } 和 { Do A; Assert C; }

避免随机数据 或诸如'datetime.now'之类的东西

确保在测试结束时将所有测试装置成员返回其原始状态（例如，使用 拆除)

即使您在生产代码中无情地删除重复，在测试固定装置中的代码重复也是一个小得多的问题。

与Farmboy已经提到的相似，我的方法名称格式

 <MethodName>Should<actionPerformed>When<Condition>

例如

 GetBalanceShouldReturnAccountBalance() {
许可以下： CC-BY-SA 和 归因
scroll top