极其琐碎方法的单元测试（是或否）

Question

假设您有一个方法：

public void Save(Entity data)
{
    this.repositoryIocInstance.EntitySave(data);
}

您会编写单元测试吗？

public void TestSave()
{
    // arrange
    Mock<EntityRepository> repo = new Mock<EntityRepository>();
    repo.Setup(m => m.EntitySave(It.IsAny<Entity>());

    // act
    MyClass c = new MyClass(repo.Object);
    c.Save(new Entity());

    // assert
    repo.Verify(m => EntitySave(It.IsAny<Entity>()), Times.Once());
}

因为稍后如果您确实更改方法的实现以执行更“复杂”的操作，例如：

public void Save(Entity data)
{
    if (this.repositoryIocInstance.Exists(data))
    {
        this.repositoryIocInstance.Update(data);
    }
    else
    {
        this.repositoryIocInstance.Create(data);
    }
}

...您的单元测试会失败，但它会失败可能不会破坏您的应用程序...

问题

我是否应该在没有任何返回类型*或**不更改内部之外的任何内容的方法上创建单元测试模拟？

Answer 1

不要忘记单元测试不仅仅是测试代码。 它允许您确定行为何时发生变化。

所以你可能会遇到一些微不足道的事情。 但是，您的实现会发生变化，并且可能会产生副作用。 您希望回归测试套件告诉您。

例如，人们经常说你不应该测试 setter/getter，因为它们很琐碎。 我不同意，不是因为它们是复杂的方法，而是有人可能会因无知、粗手指场景等而无意中改变它们。

鉴于我刚才所说的一切，我肯定会实现上述测试（通过模拟，和/或也许值得在设计您的类时考虑到可测试性并让它们报告状态等。）

Answer 2

确实，您的测试取决于您的实现，这是您应该避免的事情（尽管有时并不是那么简单......）并且不一定是坏事。 但是，即使您的更改不会破坏代码，此类测试也有望突破。

您可以有很多方法来实现这一点：

• 创建一个真正进入数据库的测试，并检查状态是否按预期更改（它不会不再是单元测试）
• 创建一个测试对象来伪造数据库并在内存中执行操作（repositoryIocInstance 的另一个实现），并验证状态是否按预期更改。 对存储库接口的更改也会引起对该对象的更改。 但你的界面应该不会有太大变化，对吧？
• 认为所有这些都太昂贵，并使用您的方法，这可能会导致以后不必要的破坏测试（但一旦机会很低，就可以冒险）

Answer 3

问自己两个问题。 “这个单元测试的手动等效项是什么？” 以及“是否值得自动化？”。 在你的情况下，它会是这样的：

什么是手动等效？
- 启动调试器
- 进入“保存”方法
- 进入下一步，确保您处于 IRepository.EntitySave 实现中

它值得自动化吗？ 我的回答是“不”。 从代码中可以看出 100% 明显。
从数百个类似的废物测试中，我没有看到一个有用的。

Answer 4

一般的经验法则是，您测试所有可能会损坏的东西。 如果您确定该方法足够简单（并且保持足够简单）不会成为问题，那么就通过测试来解决这个问题。

第二件事是，您应该测试方法的契约，而不是实现。 如果测试在更改后失败，但应用程序没有失败，那么您的测试测试的不是正确的。 测试应涵盖对您的应用程序重要的案例。 这应该确保对方法的每次更改不会破坏应用程序，也不会导致测试失败。

Answer 5

不返回任何结果的方法仍然会更改应用程序的状态。 在这种情况下，您的单元测试应该测试新状态是否符合预期。

Answer 6

“你的单元测试会失败，但它可能不会破坏你的应用程序”

这实际上是非常重要的。 这可能看起来很烦人和微不足道，但是当其他人开始维护您的代码时，他们可能对“保存”做了非常糟糕的更改，并且（不太可能）破坏了应用程序。

诀窍是确定优先顺序。

首先测试重要的东西。 当事情进展缓慢时，为琐碎的事情添加测试。

Answer 7

当方法中没有断言时，您实际上是在断言不会引发异常。

我还在努力解决如何测试 public void myMethod() 的问题。 我想如果您确实决定添加返回值以实现可测试性，则返回值应该代表查看应用程序状态发生了什么变化所需的所有显着事实。

public void myMethod()

成为

 public ComplexObject myMethod() { 
 DoLotsOfSideEffects()
 return new ComplexObject { rows changed, primary key, value of each column, etc };
 }

而不是

public bool myMethod()  
  DoLotsOfSideEffects()
  return true;

Answer 8

对您问题的简短回答是：是的，您绝对应该测试这样的方法。

我认为 Save 方法实际上保存数据是重要的。 如果您不为此编写单元测试，那么您怎么知道呢？

其他人可能会删除调用 EntitySave 方法的那行代码，并且任何单元测试都不会失败。 后来，您想知道为什么项目永远不会被持久化......

在您的方法中，您可以说删除该行的任何人只有在有恶意的情况下才会这样做，但事实是：简单的事情不一定保持简单，并且您最好在事情变得复杂之前编写单元测试。

Save 方法在存储库上调用 EntitySave 并不是一个实现细节 - 它是预期行为的一部分，并且是一个非常关键的部分（如果我可以这么说的话）。 您想要确保数据确实被保存。

仅仅因为方法不返回值并不意味着它不值得测试。 一般来说，如果您观察到良好的命令/查询分离 (CQS)，则任何 void 方法都应该会更改某事物的状态。

有时，某个东西是类本身，但有时，它可能是其他东西的状态。 在这种情况下，它会更改存储库的状态，这就是您应该测试的内容。

这称为测试间接输出，而不是更正常的直接输出（返回值）。

诀窍是编写单元测试，这样它们就不会经常中断。 使用 Mock 时，很容易意外编写过度指定的测试，这就是为什么大多数动态 Mock（如 Moq）默认为 Stub 模式，在这种模式下，如何编写并不重要您多次调用给定的方法。

所有这些以及更多内容，都在优秀的 xUnit 测试模式中进行了解释。