Comments 6
Судя по наличию комментариев тесты в tsql так же актуальны как тестирование в cobol, что несомненно радует. Главный вопрос, без сарказма, зачем все это нужно (я про тесты именно в tsql), кто говорит тесты, говорит mock и другие плюшки, а их в tsql нет и не будет.
Расскажите, как решена проблема копирования гигантского объёма данных при моке таблицы, да еще, насколько я предполагаю, выполняемая каждый раз при запуске тестов?
Копирование гигантский объемов не происходит, так как оригинальная таблица не удаляется, а переименовывается. Фиктивная таблица создается пустой.

При вызове FakeTable tSqlt делает буквально следующее:
  1. Генерирует уникальное имя (например tSQLt_tempobject_c2c0998aebe0498babc38c20b3e98173)
  2. Переименовывает с помощью sp_rename оригинальную таблицу с данными, задавая ей это автоматически созданное имя.
  3. Сохраняет маппинг «оригинальное имя объекта — сгенерированное имя» в таблицу Private_RenamedObjectLog
  4. Создает новую таблицу с точно такой же структурой, как и у оригинала, но БЕЗ данных.
  5. Помечает фиктивную таблицу с помощью sp_addextendedproperty.


После завершения тестов транзакция откатывается и оригинальная таблица переименовывается обратно.
Интересует мнение людей, которые продолжительное время используют tSQLt. Есть ли еще вразумительные GUI по работе с tSQLt кроме SQL Test и Unit Test. Желательно бесплатных.
Есть поддержка в Devart dbForge Studio, которая бесплатна для русских разработчиков и оставляется далеко позади MS Management Studio.
Про этот тул уже давно знаю :) dbForge Studio весьма хороша, но строго в своей епархии. Тут имею ввиду, дата и схема компараторы и SQL Complete которым регулярно пользуюсь. Остальное дело вкуса. Если брать рутинные задачи мне тоже SSMS вполне хватает. Надеюсь в новой версии скоро темную тему прикрутят.
Only those users with full accounts are able to leave comments. Log in, please.