1

我为实际和预期定义了两个表，具有完全相同的架构。我将两行插入到预期的表中，ID 为 2、1。

我跑

INSERT INTO actual EXEC tSQLt.ResultSetFilter 1, '{statement}'

填充实际然后

EXEC tSQLt.AssertEqualsTable @expected = 'expected' , @actual = 'actual'

比较结果。

即使数据的顺序不同（实际 ID 为 1、2），测试也通过了。

我通过在测试中添加 SELECT * FROM 实际和 SELECT * FROM 预期并使用 tSQLt.Run '{test name}' 自行运行测试来确认数据不同。

有谁知道这是否是一个已知的错误？显然它应该检查每行，所以应该检查排序。返回的所有其他列都是 NULL，它只是包含值的 ID 列。

4

1 回答 1

3

除非在 select 语句中指定了 order by 子句，否则 SQL Server 不保证该顺序（请参阅此 MSDN 页面上的顶部要点） - 尽管实际上它通常按照您的预期排序。

正因为如此，我相信 tSQLt 寻找不相同和相同的行是有意义的——但检查顺序没有——否则答案可能会随 SQL 服务器的一时兴起而改变，并且测试将毫无意义（更糟糕的是——间歇性失败！）。AssertEqualsTable 上的 tSQLt用户指南声明它检查表的内容，但没有检查其中的顺序。是什么让您得出结论，也应该检查订单？我找不到提及它。

如果您需要检查订单，您可以将预期结果和实际结果插入带有标识列的临时表（或使用 ROW_NUMBER）并检查结果表 - 如果订单不同，则标识列会不同。

Greg M Lucas 的博客上记录了一个类似的方法。

不建议在没有 order by 子句的情况下依赖从表返回的顺序（MSDN 链接） - 所以我建议在应用程序对语句的调用中包含一个，或者如果返回行的顺序很重要，则在其中包含一个 SP .

于 2012-10-18T07:00:07.323 回答