Question

我们有一个尽可能遵循MVP模式的LOB Winforms应用程序。

在每个新版本中，我们都希望测试任何回归。

目前的方法是，每次测试人员出现错误/崩溃时，我们都会重现该错误，然后使用NUnit插入测试。通常此测试会尝试重现用户遵循的操作链，因此我们最终会得到以下测试：MenuX_OperationY_buttonDoZ_Click_ERROR_DESCRIPTION()

测试通常准备上下文，加载数据，并执行用户单击的操作以重现错误。然后修复错误并重新运行测试。等等......直到我们有大量的现有（回归？）测试。这种测试的例子是：

[Test]
public void MenuX_OperationY_buttonDoZ_Click_ERROR_DESCRIPTION()
{
    // The presenter prepares Context & Load Data associated with Menu X
    PrsMenuX.PrepareContext();
    PrsMenuX.LoadData();

    // Do Operation Y
    PrsMenuX.OperationY();

    // Click on Button Do Z
    try
    {
        PrsMenuX.ButtonDoZ_Click();
    }
    catch (Exception ex)
    {
        Assert.Fail(ex.Message);
    }
}

所以我的问题是，这是正确的方法吗？是NUnit这个的正确工具，以及如何改进这个？测试是否应该重现用户的操作，还是我们应该只测试组成每个用户操作的低级函数？

Answer 1

这取决于失败的原因。如果它是您的代码中的算法中的一个失败的错误，那么它可能应该通过单元测试来测试。如果它更多是意外的使用错误，那么它应该是更高级别的接受/行为测试。仅仅因为你添加单元测试并不意味着你不应该添加更高级别的测试。

通常在发现错误后添加测试似乎有点迟了。如果在添加新功能或编辑现有功能时编写测试会更好。在编写代码的同时编写好的测试通常更容易，而不是在以后编写针对未知或遗忘代码的测试。实践这一点将使更多的错误从一开始就没有被引入。

回归测试的例子＆amp;单元测试 - Windows窗体LOB应用程序

1 个答案: