tSQLt является структурой модульного тестирования, поэтому базовая структура модульного теста должна быть:
Assemble , которая может включать:
- Поддельные таблицы, представленияили функции, следите за любыми процедурами
- Установите любые данные, которые должны существовать для теста
- Определите любые ожидаемые наборы результатов (например, если тестируете выходные данные из вида)
Не все тесты будут иметь Assemble step
Act : Обычно это будет вызов хранимой процедуры или функции или SELECT из представления,Если при тестировании ограничений таблицы или триггеров этот шаг может включать вставку данных в таблицу, большинство тестов будет иметь шаг Act , хотя это не является обязательным - например, шаг Assemble может подделать и заполнить некоторыетаблицы, которые управляют содержимым определенного представления и определяют ожидаемые результаты, тогда шаг Assert можно использовать для сравнения всего содержимого представления с ожидаемым набором результатов.
Assert , который может включать:
- Сравнение результатов из оператора SELECT, просмотра содержимого, вывода функции или процедуры с предопределенным набором результатов
- Проверка того, что исключение былоили не был выдан
- Проверка того, что была вызвана другая хранимая процедура (с использованием tSQLt.SpyProcedure)
- и т. д.
В каждом тесте должно быть (предпочтительно точно) одно утверждение(хотя строка кода для проверки исключений будет расположена перед актом).
Итак, учитывая вышеизложенноеи ваши требования, что данные могут измениться только в результате какого-либо действия (в процедуре или триггере, или с помощью прямого оператора DML), поэтому ваш тест обязательно должен иметь шаг Act .Я не могу понять, как вы написали бы тест tSQLt, чтобы утверждать, что любое изменение данных находится в пределах вашего допуска, независимо от процесса, который его изменяет.Когда вы проведете этот тест?После какого процесса или всех процессов?Это не модульный тест, это интеграционный тест.На самом деле, возможно, это на самом деле часть вашей логики приложения / программы.
Если вам нужно убедиться, что изменение значения никогда не выходит за пределы допустимого уровня в вашей базе данных (для двух таблиц), вы можете попробовать что-нибудьнапример:
1) Используйте триггер, который выдает исключение, если при вставке или обновлении таблицы A значение в столбце Баланс таблицы A больше или меньше, чем эквивалентзначение в таблице B
2) Запишите первый тест для этого триггера, в котором утверждается, что если значение в таблице A изменяется в пределах вашего уровня допуска, то ошибка не выдается.Эта логика может выглядеть следующим образом:
Assemble : поддельная таблица A и таблица B (tSQLt.Faketable). Повторное применение триггера к поддельной таблице A (tSQLt.ApplyTrigger). Добавление строки в обе таблицы TableA.и tableB, которая представляет вашу начальную точку
Assert : вызов tSQLt.ExpectNoException
Act : обновите строку в TableA, указав значение в пределахbounds
3) Напишите следующий тест для этого триггера, в котором утверждается, что если значение в таблице A изменяется вне вашего уровня допуска, то выдается ошибка.
Сборка : поддельная таблица A и таблица B (tSQLt.Faketable). Повторно примените триггер к поддельной таблице A (tSQLt.ApplyTrigger). Добавьте в TableA и tableB строку, представляющую начальную точку
Подтвердить : Позвоните tSQLt.ExpectException, опционально определяя ожидаемый номер ошибки и / или сообщение
Act : Обновите строку в TableA значением, которое находится за пределами вашего допускаУровень.
Я настоятельно рекомендую вам потренироваться test-first development, поэтому начните с написания обоих тестов, первый должен пройти, а второй потерпит неудачу.Затем, когда вы создаете свой триггер, оба теста должны пройти, и вы можете доказать, что требуемая логика как в положительном, так и в отрицательном случаях действительна.
Наконец, проблема этого логического подхода, основанного на базе данных, заключается в том, что ваше приложение должно будет обработать эту ошибку.Такая логика, вероятно, лучше размещена в приложении.В конце концов, база данных - не Python, поэтому в этом случае LBYL (Look Before You Leap) лучше, чем EAFP (проще просить прощения за такое разрешение)