Question

在编写单元测试时，是否有一种简单的方法可以确保没有发生任何意外情况？

由于可能的副作用列表是无限的，添加大量的Assert以确保在每个步骤都没有任何改变似乎是徒劳的，并且它模糊了测试的目的。

我可能错过了一些框架功能或良好做法我使用的是C＃7，.net 4.6，MSTest V1。

编辑：更简单的例子是测试视图模型的setter，应该发生两件事情：值应该改变，应该引发PropertyChanged事件。这两件事很容易检查，但现在我需要确保其他属性值没有改变，没有引发其他事件，系统剪贴板没有被触及......

Answer 1

你错过了单元测试的重点。他们是“证明”。你不能在逻辑上证明一个消极的断言，所以即使尝试也没有意义。

每个单元测试中的断言应该证明所需的行为已经完成。就是这样。

如果我们将问题简化为荒谬，那么每个单元测试都要求我们断言被测函数没有启动热核战争。

单元测试不是您需要执行的唯一类型的测试。有功能测试，集成测试，可用性测试等。每个都有自己的重点。对于单元测试，重点是证明单个函数的预期行为。因此，如果该函数应该完成两件事，那就断言这两件事中的每一件都发生了，继续前进。

Answer 2

确保没有“坏”或意外发生的选项之一是确保使用依赖注入和模拟的良好实践：

[Test]
public void TestSomething()
{
    // Arrange
    var barMock = RhinoMocks.MockRepository.GenerateStrictMock<IBar>();
    var foo = new Foo(barMock);
    // Act
    foo.DoSomething();
    // Assert
    ...
}

在上面的示例中，如果Foo意外触及Bar，则会导致异常（严格模拟）并且测试失败。这种方法可能并不适用于所有测试案例，但可以作为其他潜在实践的良好补充。

Answer 3

编辑的一些补充：

在Test Driven Development中，您只编写代码，这将通过测试，仅此而已。此外，您希望选择最简单的solutoin来实现这一目标。

那就是说你很可能会在失败的单元测试中开始。在您的情况下，您不会在开始时获得失败的单元测试。

如果将其推到极限，则在检查每个结果时，必须检查应用程序中是否未调用format C:\。你可能想看一下像KISS - 原则这样的设计原则（保持简单，愚蠢）。

Answer 4

如果＆＃34;的范围检查没有其他事情发生＆＃34;是为了确保模型的状态没有变化，从问题出现的情况就是这样。

编写一个辅助函数，在事件和模型之前获取模型并对其进行比较。让它返回已更改的属性，然后您可以断言只有那些您要更新的属性在返回列表中。这种助手是便携式，可维护的和可重复使用的

检查模型状态是单元测试的有效应用。

Answer 5

只有在引用透明的语言（例如Safe Haskell）中才有可能。

断言＆＃34;什么都没发生＆＃34;在写单元测试时

5 个答案: