tSQLt AssertEqualsTable - unexpected results when table schema doesn't match -

i noticed other day can write test there more columns in actual table in expected table , test still pass if the data matches in columns exist in both.

here example:

if exists(select * information_schema.routines routine_schema='unittests_firsttry' , routine_name='test_assertequalstable_ignoresextracolumnsinactual') begin     drop procedure  unittests_firsttry.test_assertequalstable_ignoresextracolumnsinactual end go  create procedure unittests_firsttry.test_assertequalstable_ignoresextracolumnsinactual begin      if object_id(n'tempdb..#expected') > 0 drop table [#expected];     if object_id(n'tempdb..#actual') > 0 drop table [#actual];  create table #expected( 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 

i noticed when removed columns expected table of test no longer needed columns, forgot remove same columns actual table , test still passed, me bit off putting. happens when actual table has more columns. if expected has more columns error generated. correct? know reasoning behind behavior?

although not particularly documented in respect, assertequalstable routine looks @ data in table - not columns same. check whether table structures same, use assertresultsetshavesamemetadata. wrote bit in article.

you can of course run both in same test, , test pass if both checks pass.

i guess reason split because there may rare instances care either data or metadata being consistent test, not both.