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

Я заметил это, когда удалил несколько дополнительных столбцов из таблицы Expected теста, которому эти столбцы больше не нужны, но я забыл удалить те же столбцы из таблицы Actual, и мой тест все еще прошел, что меня немного смутило. Это происходит только тогда, когда в фактической таблице больше столбцов. Если ожидаемое количество столбцов больше, генерируется ошибка. Это правильно? Кто-нибудь знает, в чем причина такого поведения?


tsqlt
person Andrew    schedule 18.07.2013    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Хотя процедура AssertEqualsTable не очень хорошо документирована в этом отношении, она просматривает только данные в таблице, а не то, что столбцы одинаковы. Чтобы проверить, совпадают ли структуры таблиц, используйте AssertResultSetsHaveSameMetaData. Я немного написал об этом в этой статье.

Конечно, вы можете запустить оба теста в одном и том же тесте, и тест будет пройден только в том случае, если обе проверки пройдены.

Я предполагаю, что причиной разделения может быть то, что могут быть редкие случаи, когда вы заботитесь о том, чтобы данные или метаданные были согласованы для вашего теста, но не оба.

person DaveGreen    schedule 18.07.2013
comment
Спасибо за ответ Дэйв. Я знал об AssertResultSetsHAveSameMetaData и рассматривал возможность написания собственного AssertEqualsTableExact, который вызывает этот процесс. перед выполнением AssertEqualsTable. Спасибо и за ссылку на вашу статью. Я читал его в прошлом и нашел некоторые из ваших советов, чтобы быть очень полезными. - person Andrew; 19.07.2013
comment
Спасибо, Андрей, рад, что статья оказалась полезной. - person DaveGreen; 19.07.2013
comment
Когда я упомянул об этом одному из парней, с которыми работал, я получил, как я подозреваю, более точный ответ на этот вопрос. Я неправильно смотрел на проблему. Меня в основном поставил в тупик тот факт, что я удалял столбцы из таблицы #Expected. Более вероятный ответ на вопрос, почему вам не нужно иметь все столбцы в таблице #Expected, таков: если у вас есть тест, использующий AssertEqualsTable для сравнения #expected и myTable в определенный момент времени, а затем через некоторое время вы добавляете новый столбец в myTable, вы получите неудачный тест, если AssertEqualsTable также сравнит столбцы - person Andrew; 15.08.2013