tSQLt AssertEqualsTable не проверяет порядок

У меня есть две таблицы, определенные для фактических и ожидаемых с точно такой же схемой. Я вставляю две строки в ожидаемую таблицу с идентификаторами, скажем, 2, 1.

я бегу

INSERT INTO actual EXEC tSQLt.ResultSetFilter 1, '{statement}'

чтобы заполнить фактическое тогда

EXEC tSQLt.AssertEqualsTable @expected = 'expected' , @actual = 'actual'

для сравнения результатов.

Несмотря на то, что данные находятся в другом порядке (фактические идентификаторы 1, 2), тест проходит.

Я подтвердил, что данные были разными, добавив SELECT * FROM actual и SELECT * FROM, ожидаемые в тесте, и запустив тест самостоятельно с помощью tSQLt.Run '{test name}'.

Кто-нибудь знает, известная ли это ошибка? По-видимому, предполагается проверка каждой строки, поэтому следует проверять порядок. Все остальные столбцы возвращаются NULL, это просто столбец идентификатора, который содержит значение.


tsqlt
person Barry King    schedule 17.10.2012    source источник

Ответы (1)


arrow_upward
3
arrow_downward

Если в операторе select не указано условие order by, порядок не гарантируется сервером SQL (см. Верхний маркер в эта страница MSDN), хотя на практике это часто бывает так, как и следовало ожидать.

Из-за этого я считаю, что tSQLt, ищущий неидентичные и идентичные строки, имеет смысл, но проверка порядка не имеет - в противном случае ответ может измениться по прихоти SQL-сервера, и тест будет бессмысленным (и, что еще хуже, периодически завершается ошибкой. !). В руководстве пользователя по AssertEqualsTable tSQLt указано, что он проверяет содержимое таблицы, но не что он проверяет порядок в нем. Что приводит вас к выводу, что заказ также следует проверять? Я не мог найти упоминания об этом.

Если вам нужно проверить порядок, вы можете вставить как ожидаемые, так и фактические результаты во временную таблицу со столбцом идентификаторов (или использовать ROW_NUMBER) и проверить результирующую таблицу - если порядок отличается, то столбцы идентификаторов будут другими.

Документирован аналогичный метод в блоге Грега М. Лукаса.

Не рекомендуется полагаться на порядок, возвращенный из таблицы, без предложения order by (ссылка MSDN) - поэтому я бы предложил включить его в вызов вашего приложения к оператору, или если внутри него SP, если порядок возвращаемых строк важен.

person DaveGreen    schedule 18.10.2012
comment
Проверка порядка, в котором результаты возвращаются в сообщении Грега, проясняет это и подтверждает ваше объяснение. Я предполагал, что AssetEqualsTable сделает это. Добавление индекса решит эту проблему. Спасибо. - person Barry King; 18.10.2012
comment
Не уверен, как они могут использовать ROW_NUMBER() без столбца в таблицах для явного моделирования порядка вставки. @Barry King: Я тоже не понимаю, как поможет индекс. Итог: таблицы равны, потому что таблица SQL не имеет упорядочивания по определению. - person onedaywhen; 31.10.2012