Подход к тестированию

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

Возник вопрос - а как подобные тесты правильно организовывать с идеологической точки зрения, ну и с технической, в плане применения каких-нибудь фреймворков?

Суть модуля - приведение структуры БД к выданному шаблону. Модуль имеет основной публичный метод, который на вход принимает параметры подключения к БД и шаблон структуры базы. На выходе говорит - "ок" (ну и в логи что-то пишет). Так же наружу предоставлен метод сбора информации о структуре указанной БД (реальной). Вся остальная логика скрыта внутри и для юнит-тестов совершенно не интересна.

Сейчас "тесты" выглядят следующим образом:
1. Апдейтеру на вход даётся шаблон БД [1] и запрашивается приведение целевой БД к шаблону.
2. У апдейтера вызывается метод сбора информации о структуре полученной БД [2].
3. Если первые два пункта закончились без ошибок и если [1] и [2] полностью совпадают, то тест считается пройденным и по той же схеме выполняются все последюущие тесты (ну, т.е. полное создание БД с нуля, добавление колонки, удаление индекса и т.д. для всех типовых сценариев).

При этом полный прогон однотипных тестов выполняется для всех типов поддерживаемых СУБД.

Вот это всё имеет смысл организовывать в виде юнит-тестов с явным заданием порядка выполнения тестов или в таких случаях применяются какие-то иные подходы?

P.S.: я не вижу особго смысла в сотнях отдельных юнит-тестов на методы типа "сгенерировать SQL для добавления колонки в БД", т.к. интеграционные тесты (они так называются?) всё равно нужно делать дабы убедиться, что на конкретной версии/настройках СУБД запрос отрабатывает. К тому же, в этом случае придётся прикручивать какие-нибудь некрасивые костыли для доступа проекта с тестами к приватным методам тестируемого модуля.

0

Вобще всю эту работу берет на себя EF - который при каждом запуске проверяет структуру БД и приводит ее к рабочей схеме классов. Если все миграции прописаны правильно, как правило, проблем не возникает.

Тестировать там вобщем то нечего.

0

Сообщение от freeba Вобще всю эту работу берет на себя EF

1. Не на всех проектах EF.
2. Использовать миграции EF в проде страшно.
3. CodeFirst-данные для мигратора EF размазаны по нескольким файлам, что усложняет сопровождение проекта.
4. Мигратор EF в принципе не умеет работать по фактической структуре БД.

Вопрос вообще не про это был ). Я просто решил немного тестирование освоить и для примера взял небольшой модуль.

0