Question

我在20082012上的VS2012中编写了存储过程单元测试，用于保存大量存储过程，表和外键的数据库。

对于每个存储过程测试，我在执行测试之前在相关表中生成几行数据。

我已经认识到这种做法会使测试对数据库更改非常敏感，尤其是对非空列或额外键的添加。

此类更改的级联影响可能导致必须保持大量测试同步。某些测试甚至可能与特定更改无关，但共享一个或多个相关表因此将无法准备。

另外，这样做的一个相当不方便的结果是，在测试条件下测试失败和准备期间关键违规失败的测试之间很难进行区分。

大规模思考工作时间的后果可能是严重的。

到目前为止，我在这个主题上找到的任何东西都太笼统了。

现在出现了一个问题：对于dev db中的测试数据与测试中生成测试数据的问题，是否存在相关的最佳实践？

Answer 1

我一直在尝试在VS2012中编写单元测试，发现它非常有限且麻烦。由你的问题引发我刚刚在tSQLt上做了一些我已经听说过的阅读，它似乎是一个更强大的测试框架。例如。它可以模拟表，存储过程等。这样可以减少依赖关系，从而最大限度地减少数据库更改的级联影响。

即使您仍想在VS2012中编写单元测试，也可以使用模拟功能。只需确保在交易中运行测试。

来自他们网站的测试示例：

CREATE PROCEDURE SalesAppTests.[test SalesReport returns revenue and commission]
AS
BEGIN
-------Assemble
    EXEC tSQLt.FakeFunction 'SalesApp.ComputeCommission', 'SalesAppTests.Fake_ComputeCommission';
    EXEC tSQLt.FakeTable 'SalesApp.Employee';
    EXEC tSQLT.FakeTable 'SalesApp.Sales';

    INSERT INTO SalesApp.Employee (EmployeeId) VALUES (1);
    INSERT INTO SalesApp.Sales (EmployeeId, SaleAmount) VALUES (1, 10.1);
    INSERT INTO SalesApp.Sales (EmployeeId, SaleAmount) VALUES (1, 20.2);

-------Act
    SELECT EmployeeId, RevenueFromSales, Commission
      INTO SalesAppTests.Actual
      FROM SalesApp.SalesReport;

-------Assert
    SELECT TOP(0) *
      INTO SalesAppTests.Expected
      FROM SalesAppTests.Actual;

    INSERT INTO SalesAppTests.Expected (EmployeeId, RevenueFromSales, Commission) 
      VALUES (1, 30.3, 1234.5678);

    EXEC tSQLt.AssertEqualsTable 'SalesAppTests.Expected', 'SalesAppTests.Actual';
END;
GO

SQL Server单元测试存储过程 - 生成testdata

1 个答案: