我有两个为实际和预期定义的表具有完全相同的模式。我在预期的表中插入了两行，其中Ids为2,1。
我跑
INSERT INTO actual EXEC tSQLt.ResultSetFilter 1, '{statement}'
填充实际的
EXEC tSQLt.AssertEqualsTable @expected = 'expected' , @actual = 'actual'
比较结果。
即使数据的顺序不同（实际上Ids为1,2），测试也会通过。
我通过在测试中添加SELECT * FROM actual和SELECT * FROM并使用tSQLt.Run'{test name}'自行运行测试来确认数据不同。
有谁知道这是否是一个已知错误？显然它应该检查每行，所以应该检查排序。所有其他列都是NULL，返回它只是包含值的ID列。
答案 0 :(得分：3)
除非在select语句中指定了order by子句，否则SQL Server无法保证顺序（请参阅this MSDN page的顶部要点） - 尽管实际上它通常按照您的预期排序。
因此，我认为tSQLt寻找不相同且相同的行是有道理的 - 但检查顺序却没有 - 否则答案可能会随着SQL服务器的突发奇想而改变，而且测试将毫无意义（并且更糟糕） - 间歇性地失败！）。 tSQLt user guide on AssertEqualsTable表示它检查表的内容，但不检查其中的排序。是什么导致您得出结论，也应该检查订单？我找不到它。
如果您需要检查订单，可以将预期和实际结果插入带有标识列的临时表（或使用ROW_NUMBER）并检查结果表 - 如果订单不同，那么标识列将是不同。
有类似的方法记录here on Greg M Lucas' blog。
不建议依赖于没有order by子句的表返回的顺序（MSDN link） - 所以我建议在你的应用程序调用语句时加入一个，或者如果是返回行的顺序很重要。