Question

问题是，在您的Application项目中使用一个方法，除了为您的测试项目生成数据之外没有其他目的是不好的做法。

我正在使用单元测试来进行粗略检查，以确保所有有效输入都将通过我的应用程序的主要方法运行，而不会出现任何错误。我基本上运行一个方法从数据库中提取每个有效的输入，然后通过应用程序的主要方法运行每个输入。如果失败，则将bool设置为false。

我用来执行此操作的代码示例如下。问题是，是否有更好的方法来执行此操作，不需要我向应用程序代码添加任何内容。下面的方法要求我在Application项目中有一个方法（TestMethod），该方法提取所有有效参数，以便通过测试项目中的主方法（CheckAvailability）运行它们。

public void SomeUnitTest()
{
    Availability Availability = new Availability();

    List<TestParam> paramList = new List<TestParam>();
    bool success = true;
    bool expected = true;

    //This method pulls every valid param from my database.
    paramList = Availability.TestMethod();

    //This foreach loop runs each one of those valid params through another method. If there is an error, 
    //success is set to false otherwise it remains true.
    foreach (TestParam s in paramList)
    {
        try
        {
            InputWrapper Wrapper = new InputWrapper();
            Wrapper.ApplicationName = s.APPname;
            Wrapper.Location = s.APPLocation;
            Availability.CheckAvailability(Wrapper);  
        }         
        catch(Exception)
        {
            success = false;
        }

        //I then assert that success remains true. If it is false, it means that
        //the method failed.
        Assert.AreEqual(expected, success);    
    }
}

Answer 1

您似乎认为测试的数据源是一个值得怀疑的事情。

首先让我说这根本不是这样，但是，（总是一个但是）你应该记住，一个好的单元测试很容易写的（也许更重要的是 - 阅读）所以理想情况下你应该在单元测试中尽可能少的层。

这会让你陷入困境：我是否确保任何阅读我测试的人都能看到测试方法并知道将要运行的所有内容，或者我是否添加了一些图层来保持测试的清洁但是增加复杂性？

与许多事情一样：你必须妥协。我认为你的单元测试可能会达到2到3层的复杂性，但绝对不应该超过它。

在您的示例中，这意味着我们可以通过提取测试数据来增加一层复杂性，以使其与实际测试分开。
这对于理解测试来说不会是一个很大的负担，但它会使编写和维护它们变得清晰。

您的问题的另一个方面引起了一些关注：您正在谈论将测试数据放在数据库中。

这不是你的生产数据库，不是吗？如果是：停止对实时数据进行测试。您需要对测试进行绝对控制，以确保不会更改测试数据，并且在您不知情的情况下环境不会发生变化（除了可能会中断实际生产数据）。

也不需要使用布尔变量：抛出的异常会自动导致错误的测试。

我会详细了解here和here这些内容，请仔细阅读并随时提出任何后续问题。

Answer 2

就个人而言，我并不相信。单元测试的目的是评估您的功能单元是否适合其用途。为此，在您的数据来自哪里并不重要，除非这是您尝试测试的方法的责任。

话虽这么说，我会更倾向于在项目中包含一组样本数据来读取，因为它允许您更容易地修改您使用的测试数据。

单元测试方法的有效输入

2 个答案: