tSQLt AssertEqualsTable - 当表格模式不匹配时的意外结果

我注意到有一天你可以编写一个测试，其中实际表格中有更多的列在Expected表格中，如果数据仍然通过测试匹配两者中存在的列。tSQLt AssertEqualsTable - 当表格模式不匹配时的意外结果

下面是一个例子：

if exists(select * from INFORMATION_SCHEMA.ROUTINES where ROUTINE_SCHEMA='UnitTests_FirstTry' and ROUTINE_NAME='test_AssertEqualsTable_IgnoresExtraColumnsInActual') 
begin 
    drop procedure UnitTests_FirstTry.test_AssertEqualsTable_IgnoresExtraColumnsInActual 
end 
go 

create procedure UnitTests_FirstTry.test_AssertEqualsTable_IgnoresExtraColumnsInActual 
as 
begin 

    IF OBJECT_ID(N'tempdb..#Expected') > 0 DROP TABLE [#Expected]; 
    IF OBJECT_ID(N'tempdb..#Actual') > 0 DROP TABLE [#Actual]; 

create table #expected(a int null) --, b int null, c varchar(10) null) 
create table #actual(a int, x money null) 
insert #expected (a) values (1) 
insert #actual (a, x) values (1, 22.51) 
--insert #expected (a, b, c) values (1,2,'test') 
--insert #actual (a, x) values (1, 22.51) 

exec tSQLt.AssertEqualsTable '#expected', '#actual' 

end 
go 

exec tSQLt.Run 'UnitTests_FirstTry.test_AssertEqualsTable_IgnoresExtraColumnsInActual' 
go

我注意到这一点，当我删除了不再需要这些列测试的预期的表一些额外的列，但我忘了从实际取出相同的列桌子和我的测试仍然通过，这对我来说有点不合适。只有当实际表格有更多列时才会发生这种情况。如果预期有更多列，则会产生错误。它是否正确？有人知道这种行为背后的推理吗？

来源

2013-07-18 Andrew

虽然在这方面没有特别好的记录，但AssertEqualsTable例程只查看表中的数据 - 而不是列相同。要检查表结构是否相同，请使用AssertResultSetsHaveSameMetaData。我写了一些关于这个in this article。

你当然可以在同一个测试中运行两个测试，并且只有两个测试都通过时测试才会通过。

我想分裂的原因是因为可能有罕见的情况下，你关心的数据或元数据一致的测试，但不是两个。

来源

2013-07-18 17:10:30 DaveGreen

感谢您的回复戴夫。我意识到AssertResultSetsHAveSameMetaData，并考虑编写我自己的调用此proc的AssertEqualsTableExact。在做AssertEqualsTable之前。感谢您的文章链接。我已经阅读过，并发现一些提示非常有帮助。 – Andrew

谢谢安德鲁，我很高兴你发现这篇文章很有用。 – DaveGreen

当我向其中一位合作伙伴提到这件事时，我得到了我怀疑这个问题更准确的答案。我以错误的方式看待问题。我基本上被我从#Expected表中删除列的事实难倒了。关于为什么不需要在#Expected表中包含所有列的更可能的答案是：如果您有一个使用AssertEqualsTable在某个时间点比较#expected和myTable的测试，并且稍后您添加一个myTable的新列，如果AssertEqualsTable也比较列，那么最终会出现一个失败的测试 – Andrew

tSQLt AssertEqualsTable - 当表格模式不匹配时的意外结果

回答

相关问题