Question

我正在为我们的核心库编写单元测试。

其中一个类测量计算机性能随时间的变化（平均值），应用一些权重并可以吐出一个数字。

现在，它用来做平均值和应用权重的类很容易进行单元测试。（抛出一些平均值，与已知结果进行比较）。不容易测试的是Workload类本身的目的，因为这将涉及强制机器处于50％的利用率，然后检查已知的，体重调整后的平均值为50％。

我知道，当然，我可以“假装”机器的利用率达到50％，并以这种方式比较结果，但在任何时候，单元测试实际上都没有针对50％的实际利用率进行测试。

您遇到的其他“困难”测试案例，如果不是不可能，您采用了哪些创造性方法来解决它？

Answer 1

您是否尝试过测试在WinForms应用程序中显示简单的MsgBox（或任何模态窗口）？在最近的一个项目中，我们花了一些时间与Win32句柄和多线程测试用例进行斗争，试图一致地验证对话框出现在屏幕上（因为它是模态的，你不能只是从你的主测试线程执行它）。这些测试在某些时候会起作用，但由于没有“好”的原因，很容易发生间歇性故障（例如，由于某些后台处理，测试期间窗口失去了焦点）。

在这种情况下，我们使用C＃delegates的强大功能来基本模拟对MsgBox.Show()的静态调用。通过声明代表，如

public delegate DialogResult ShowDelegate(string text, string caption);

我们可以在生产中使用new ErrorMessageHelper(MsgBox.Show)，测试看起来像

[TestFixture]
public class ErrorDialogHelperTest
{
    [Test]
    public void UsesShowDelegateToDisplayMessage()
    {
        bool delegateWasCalled = false;
        ShowDelegate mockShowDelegate = delegate(string text, string caption)
        {
            Assert.AreEqual("the expected message", text);
            Assert.AreEqual("the expected title", caption);
            delegateWasCalled = true;
        };

        ErrorDialogHelper helper = new ErrorDialogHelper(showDelegate);

        helper.ShowErrorMessage("the expected message", "the expected title");
        Assert.IsTrue(delegateWasCalled);
    }
}

我们当然有进一步的测试来验证我们确实使用MsgBox.Show构建了生产实例。我在这个例子中使用MsgBox，但是我们使用了类似的技术来测试所有模态窗口的显示。

另一个经典难以测试的示例是您的代码需要消耗挂钟日期和时间。同样，解决方案是引入一个可以从测试中控制的假时钟。在这两种情况下，您都依赖底层框架或系统实现来正常工作，并且只测试所有内容是否正确连接。是否合理风险应根据具体情况确定。

一些困难的单元测试有哪些例子，要么是不可能的，要么是创造性地解决了？

1 个答案: