单元测试方法的有效输入

Question

问题是，在您的应用程序项目中拥有一个除了为您的测试项目生成数据之外没有其他目的的方法是否是一种糟糕的做法。

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

您似乎认为测试的数据源是一个有问题的东西。

首先，我要说的是，情况完全不是这样，但是，（总是有一个but）您应该记住，一个好的单元测试是非常容易编写的（而且--也许更重要的是--阅读），所以在理想情况下，您的单元测试中应该有尽可能少的层。

这就给您带来了一个困境：我是确保任何阅读我的测试的人都可以仅仅查看测试方法并了解将要投入运行的所有内容，还是我添加了一些层来保持测试干净，但也增加了复杂性？

就像很多事情的情况一样：你将不得不妥协。我认为您可以在单元测试中增加2层或3层的复杂性，但绝对不应该超过这一层。

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

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

这不是你的生产数据库吧？如果是：停止针对活动数据的测试。您需要对测试进行绝对的控制，以确保没有测试数据被更改，并且环境不会在您不知道的情况下发生更改（除了实际生产数据的潜在中断）。

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

我将在这里和这里更详细地介绍这些事情，请通读它们，并随时提出任何后续问题。