Comments 6
Судя по наличию комментариев тесты в tsql так же актуальны как тестирование в cobol, что несомненно радует. Главный вопрос, без сарказма, зачем все это нужно (я про тесты именно в tsql), кто говорит тесты, говорит mock и другие плюшки, а их в tsql нет и не будет.
Расскажите, как решена проблема копирования гигантского объёма данных при моке таблицы, да еще, насколько я предполагаю, выполняемая каждый раз при запуске тестов?
Копирование гигантский объемов не происходит, так как оригинальная таблица не удаляется, а переименовывается. Фиктивная таблица создается пустой.
При вызове FakeTable tSqlt делает буквально следующее:
После завершения тестов транзакция откатывается и оригинальная таблица переименовывается обратно.
При вызове FakeTable tSqlt делает буквально следующее:
- Генерирует уникальное имя (например tSQLt_tempobject_c2c0998aebe0498babc38c20b3e98173)
- Переименовывает с помощью sp_rename оригинальную таблицу с данными, задавая ей это автоматически созданное имя.
- Сохраняет маппинг «оригинальное имя объекта — сгенерированное имя» в таблицу Private_RenamedObjectLog
- Создает новую таблицу с точно такой же структурой, как и у оригинала, но БЕЗ данных.
- Помечает фиктивную таблицу с помощью sp_addextendedproperty.
После завершения тестов транзакция откатывается и оригинальная таблица переименовывается обратно.
Есть поддержка в Devart dbForge Studio, которая бесплатна для русских разработчиков и оставляется далеко позади MS Management Studio.
Про этот тул уже давно знаю :) dbForge Studio весьма хороша, но строго в своей епархии. Тут имею ввиду, дата и схема компараторы и SQL Complete которым регулярно пользуюсь. Остальное дело вкуса. Если брать рутинные задачи мне тоже SSMS вполне хватает. Надеюсь в новой версии скоро темную тему прикрутят.
Sign up to leave a comment.
tSqlt — модульное тестирование в Sql Server