#tdd #tsqlt
Вопрос:
Я ценю, что это, вероятно, не то место, чтобы спрашивать, если есть место получше, пожалуйста, дайте мне знать.
У меня есть устаревшая хранимая процедура, которая выбирает некоторые данные и вставляет их в таблицу. Однако есть довольно много примеров, которые я хотел бы проверить, и мне было интересно, как это следует сделать.
insert into [dbo].[utb_ITP] ... case when [sme].[Reporting Countries] = 'Multiple Countries' then 'United Kingdom-Multiple Countries' when patindex('%-
Я думаю, что все образцы, которые я видел, были издевательствами над данными и функциями тестирования, но на самом деле я не видел примеров, подобных описанию случая. Тестирую ли я конечный результат или составные части? Поэтому я бы сначала проверил
[sme].[Reporting Countries] = 'Multiple Countries' then 'United Kingdom-Multiple Countries'
В этом случае я бы использовал AssertEqualsTable, где ожидаемое значение было бы "Великобритания-Несколько стран", а затем вставка в Фактическое выполняла бы первую часть дела, что-то вроде:
insert into #Expected values ('United Kingdom-Multiple Countries') insert into #Actual select case [sme].[Reporting Countries] = 'Multiple Countries' then 'United Kingdom-Multiple Countries' end from [SourceTable] as [sme] where [sme].[Reporting Countries] = 'Multiple Countries' exec AssertEqualsTable ...
Ответ №1:
Вы на правильном пути. Вы действительно хотите изолировать эти ветви вашего CASE заявления. Это означает, что вам нужно написать один тест для каждой возможной ветви в нем.
Вы также хотите изолировать эти тесты от других функций. Это означает, что подделайте все задействованные таблицы, а затем вставьте достаточное количество строк (вероятно, 1 в этих тестах), чтобы доказать это. tSQLt.FakeTable позволяет помещать данные только в те столбцы, которые имеют отношение к тестированию данной конкретной функции. В вашем случае это выглядит так, как будто это может быть просто [sme].[Reporting Countries] колонка.
Итак , вы хотите написать один тест для 'Multiple Countries' , два для тестирования PATINDEX (например 'value-withdash' , и 'othervalue-withdash' ) и, наконец, один для ELSE ветви (например 'other value without dash' ).
В тестах я, как правило, уделяю больше внимания тому, чтобы цель теста была ясной, чем тому, чтобы значения были реалистичными.
Если у вас есть другие операторы case INSERT , напишите для них независимые тесты по той же схеме.
,[sme].[Reporting Countries) gt; 1 then left([sme].[Reporting countries], (pat index('%-%', [sme].[Reporting Countries]) - 1 )) else [sme].[Reporting Countries] end as [SVC_COUNTRY] Я думаю, что все образцы, которые я видел, были издевательствами над данными и функциями тестирования, но на самом деле я не видел примеров, подобных описанию случая. Тестирую ли я конечный результат или составные части? Поэтому я бы сначала проверил
В этом случае я бы использовал AssertEqualsTable, где ожидаемое значение было бы «Великобритания-Несколько стран», а затем вставка в Фактическое выполняла бы первую часть дела, что-то вроде:
Ответ №1:
Вы на правильном пути. Вы действительно хотите изолировать эти ветви вашего CASE заявления. Это означает, что вам нужно написать один тест для каждой возможной ветви в нем.
Вы также хотите изолировать эти тесты от других функций. Это означает, что подделайте все задействованные таблицы, а затем вставьте достаточное количество строк (вероятно, 1 в этих тестах), чтобы доказать это. tSQLt.FakeTable позволяет помещать данные только в те столбцы, которые имеют отношение к тестированию данной конкретной функции. В вашем случае это выглядит так, как будто это может быть просто [sme].[Reporting Countries] колонка.
Итак , вы хотите написать один тест для 'Multiple Countries' , два для тестирования PATINDEX (например 'value-withdash' , и 'othervalue-withdash' ) и, наконец, один для ELSE ветви (например 'other value without dash' ).
В тестах я, как правило, уделяю больше внимания тому, чтобы цель теста была ясной, чем тому, чтобы значения были реалистичными.
Если у вас есть другие операторы case INSERT , напишите для них независимые тесты по той же схеме.