Комментарии 12
Ни слова конкретики.
Я вот много лет рабоиал с разной сложности информационными системами. И Мне вот чисто гипотетически интересно, как можно за 30 секунд пройти все бизнес процессы в "сложно связанной системе".
Пару примеров не помешало бы
Вот я не знаю, что именно вы вклпдываете в термин "юнит тесты"… Я не предсиавляю, как можно за указанное время, да даже просто пересобрать пакет или создать набор фейковой схемы БД с тестовым набором данных (если это не запросы вида SELECT TRUE FROM DUAL. Проверку процедур и функций на валидность? Так это делает сама субд на этапе компиляции. Непротиворечивость? Так это опять делает сама СУБД средствами ограничейний целостности.
За 30 секунд не любой коммит то пройдёт… А как вы тестируете оптимизацию в гипер-больших отношениях? Как анализируется оптимальность семаниисеской модели? Наличие, правильность и оптимальность создания индексных структур, ключей, триггеров и вообще процесса нормализации и контролируемой избыточности?
Как и где выводятся метрики планов запросов в тестируемых пакетах на данных разного размера? А как тестируется связи с внешними систеиами?
И тд и тп… Это самые основные задачи в разработке СУБД. а то, что вы тестируете за 30 секунд. Это шляпа какая то и попахивает профанацией.
И ладно бы, но это как с масками сейчас. По рекомендации ВОЗ их нужно носить только больным, так как они дают ложное ощущение защиты.
Так и у вас. Эти ваши юнит тесты дабт ложное ощущение контроля и можно проморгать большой пипец.
Я так понял, исходя из текста статьи и того, что её автор пишет в комментариях, что:
- Это не единственный вид тестов в их проекте
- Тестируется всякая логика типа: «сработал ли триггер при вставке в таблицу» или «правильно ли отработала огромная хранимая процедура на тестовых данных» и т.п.
Если много логики сделано в виде хранимых процедур, то почему бы это не покрыть тестами?
Интересно как тестируются процедуры которые изменяют данные? (А что еще должен делать код в пакаджах базы? Это как бы его основная задача).
Раскатать тестовый набор данных прогнать тесты и откатить состояние к первоначальному?
Тем более непростой становится задача если тесты запускаются параллельно и/или в произвольном порядке.
Приёмочное, end to end, функциональное, интеграционное (или любой другой термин) тестирование это не замена, а дополнение к изолированному unit тестированию системы.
В чём проблемы:
1) Функциональные тесты намного сложнее писать. Представим, что мы проверяем бизнес-процессы интернет магазина, который безусловно интегрирован с базой данной лояльности. Но в цепочке «интернет магазин — база данных лояльности» используется ещё десяток микросервисов. Поэтому, чтобы писать такие тесты, нужно
— хорошо представлять архитектуру всей системы
— иметь эталонный набор данных во всех системах
— обеспечить что все системы находятся в валидном состоянии на тестовых контурах
2) Функциональные тесты работают существенно дольше, чем unit тесты. Например, клиент делает покупку и получает за неё бонусы. Факт покупки нужно обеспечить максимально быстро, а вот бонусы начисляются асинхронно в течение какого-то времени после покупки. Внутри системы мы можем дёргать нужные методы и сделать проверку процесса мгновенным, а что делать фронту?
3) Большой процент функционала в принципе может не иметь возможности быть покрытым функциональными тестами. Например, у нас в бд лояльности очень много логики, которая ни на какие фронты не вынесена.
Но функциональные тесты безусловно нужны, просто это отдельный уровень тестирования, который обычно осуществляется на изолированных серверах и отдельными командами. В Спортмастере мы таким также занимаемся.
Unit-тесты в СУБД — как мы делаем это в Спортмастере, часть третья