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 - 當表格模式不匹配時的意外結果

回答

相關問題