Question

我目前正在寻找使用tSQLt为某些SQL Server SQL代码编写一些单元测试。

在阅读文档之后，似乎不支持能够使用参数调用测试用例，而不是为每个参数组合编写单独的测试用例。 （为了这个问题，请放在一边，你是否认为将参数传递给测试用例与为每个参数组合分别编写一个参数是个好主意）

例如在NUnit中，您可以使用TestCase属性执行以下操作：

[TestCase("", -1, false)]
[TestCase("ACT ", 1, true)]
[TestCase("ACT", 1, true)]
[TestCase("aCT", 1, true)]
[TestCase("AUSTRALIAN CAPITAL TERRITORY", 1, true)]
[Test]
public void DetermineStateIdFromText(string aStateText, long aExpectedStateId, bool aExpectedFound)
{
    //Arrange
    WzDetermineStateIdFromTextInput input = new WzDetermineStateIdFromTextInput
                                            {
                                                StateText = aStateText
                                            };

    //Act
    WzDetermineStateIdFromTextOutput output = _WzLocationMappingService.DetermineStateIdFromText(input);

    //Assert
    output.ResultSuccess.ShouldBeTrue();
    output.Found.ShouldBe(aExpectedFound);
    if (output.Found)
    {
        output.StateId.ShouldBe(aExpectedStateId);
    }
}

（测试方法的内容是无关紧要的，仅仅是为了完整性.IllBe（）调用来自Shouldly，以防你想知道Asserts在哪里。）

有没有人在tSQLt中提供任何提供TestCase样式支持的解决方案？

Answer 1

tSQLt允许使用不是测试类中的测试用例的存储过程。因此，为了实现您正在寻找的东西，我通常会创建一个接受参数并处理所有测试逻辑的存储过程。然后我写了一堆单行测试程序，调用其他程序传入适当的参数。在tSQLt本身的测试用例中有一些例子。

这种方法与真正的参数化测试相比具有很少的缺点，但是有一个很大的优势：您可以为每个案例提供一个真正有意义的名称，这将使问题变得更加简单。（真正的参数化测试在积压工作中，但它们不是最高优先级，所以它们可能需要一段时间才能完成。）

作为旁注，我强烈反对自动生成测试甚至测试参数，因为这通常会导致更高的维护成本。由于测试的目标是降低维护代码库的成本，这会适得其反。我已经看到很多单元测试采用项目因为这个原因而失败。

在tSQLt中获得Nunit样式TestCase（）功能的任何解决方案？

1 个答案: