在tSQLt中获得Nunit风格的TestCase()功能的任何解决方案? [英] Any solutions to getting Nunit style TestCase() functionality in tSQLt?

查看:181
本文介绍了在tSQLt中获得Nunit风格的TestCase()功能的任何解决方案?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

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

I am currently looking to write some unit tests for some SQL Server SQL code using tSQLt.

阅读文档后,似乎不支持能够使用参数调用测试用例,而不是为每个参数组合编写单独的测试用例. (出于这个问题,请撇开您是否认为将参数传递给测试用例与为每个参数组合编写一个单独的参数相比是个好主意)

After reading the docs it appears that there is no support for being able to call a test case with parameters, instead of writing separate test cases for each parameter combination. (For the sake of this question please put aside whether you think it is a good idea to pass parameters to a test case vs writing a separate one for each parameter combination)

例如,在 NUnit 中,您可以使用

For instance in NUnit you can do something as follows using the TestCase attribute:

[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);
    }
}

(测试方法的实质无关紧要,仅出于完整性考虑而包括在内.ShouldBe()调用来自应该,以防您想知道断言在哪里.)

(The guts of the test method are irrelevant and are included just for completeness. The ShouldBe() calls are from Shouldly in case you are wondering where the Asserts are.)

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

Has anyone got any solutions to providing TestCase style support within tSQLt?

推荐答案

tSQLt允许使用不是测试类中的测试用例的存储过程.因此,要实现您想要的目标,我通常创建一个存储过程,该存储过程接受参数并处理所有测试逻辑.然后,我编写了一堆单行测试过程,这些过程调用其他过程并传递适当的参数.在tSQLt本身的测试案例中,有一些示例.

tSQLt allows the use of stored procedures that are not test cases within test classes. So to achieve, what you are looking for, I usually create a stored procedure that accepts parameters and handles all the test logic. Then I write a bunch of single line test procedures that call the other procedure passing in the appropriate parameters. There are a few examples for this in the test cases for tSQLt itself.

与真正的参数化测试相比,这种方法几乎没有缺点,但是有一个很大的优点:您可以为每个案例指定一个真正有意义的名称,这将使查找问题变得更加简单. (真正的参数化测试处于待办事项中,但它们不是最高优先级,因此可能要花一些时间.)

This approach has very few disadvantages over truly parameterized tests, but one big advantage: You can give each case a truly meaningful name that will make hunting down issues a lot simpler. (True parameterized tests are on the backlog, but they are not the highest priority, so it might be a while for them to make it.)

作为一个旁注,我强烈建议您不要自动生成测试,甚至不建议使用测试参数,因为这通常会导致维护成本增加.测试的目的是减少维护代码库的成本,这会适得其反.正因为如此,我已经看到许多单元测试采用项目失败.

As a side note, I strongly advise against autogenerating tests or even parameters for tests, as that usually leads to higher maintenance costs. As the goal of testing is to reduce the cost of maintaining your codebase, that is counterproductive. I've seen a lot of unit testing adoption projects fail because of that very reason.

这篇关于在tSQLt中获得Nunit风格的TestCase()功能的任何解决方案?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
相关文章
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆