Как стать автором
Обновить

Комментарии 12

Ни слова конкретики.
Я вот много лет рабоиал с разной сложности информационными системами. И Мне вот чисто гипотетически интересно, как можно за 30 секунд пройти все бизнес процессы в "сложно связанной системе".
Пару примеров не помешало бы

Приму к сведению и пройдёмся по примерам в следующих выпусках

Вот я не знаю, что именно вы вклпдываете в термин "юнит тесты"… Я не предсиавляю, как можно за указанное время, да даже просто пересобрать пакет или создать набор фейковой схемы БД с тестовым набором данных (если это не запросы вида SELECT TRUE FROM DUAL. Проверку процедур и функций на валидность? Так это делает сама субд на этапе компиляции. Непротиворечивость? Так это опять делает сама СУБД средствами ограничейний целостности.
За 30 секунд не любой коммит то пройдёт… А как вы тестируете оптимизацию в гипер-больших отношениях? Как анализируется оптимальность семаниисеской модели? Наличие, правильность и оптимальность создания индексных структур, ключей, триггеров и вообще процесса нормализации и контролируемой избыточности?
Как и где выводятся метрики планов запросов в тестируемых пакетах на данных разного размера? А как тестируется связи с внешними систеиами?
И тд и тп… Это самые основные задачи в разработке СУБД. а то, что вы тестируете за 30 секунд. Это шляпа какая то и попахивает профанацией.
И ладно бы, но это как с масками сейчас. По рекомендации ВОЗ их нужно носить только больным, так как они дают ложное ощущение защиты.
Так и у вас. Эти ваши юнит тесты дабт ложное ощущение контроля и можно проморгать большой пипец.

Любое тестирование подразумевает под собой какие-либо компромиссы. Где-то нужно обращение к внешнему сервису «замокать», где-то ещё что-то. Особенно если речь идёт о юнит-тестах, где тестируются изолированно по сути отдельные функции. То есть «тестируете оптимизацию в гипер-больших отношениях», «как тестируется связи с внешними системами» — это вообще не про юнит-тесты.
Я так понял, исходя из текста статьи и того, что её автор пишет в комментариях, что:
  1. Это не единственный вид тестов в их проекте
  2. Тестируется всякая логика типа: «сработал ли триггер при вставке в таблицу» или «правильно ли отработала огромная хранимая процедура на тестовых данных» и т.п.

Если много логики сделано в виде хранимых процедур, то почему бы это не покрыть тестами?
+1 к предыдущему комментарию.
Интересно как тестируются процедуры которые изменяют данные? (А что еще должен делать код в пакаджах базы? Это как бы его основная задача).
Раскатать тестовый набор данных прогнать тесты и откатить состояние к первоначальному?
Тем более непростой становится задача если тесты запускаются параллельно и/или в произвольном порядке.
Вы правы, что основная цель автотестов это не просто прогнать код, а убедиться, что база получила надлежащее состояние. Именно этим мы и занимаемся.

Ничего нового тут не изобретено — изоляция зависимостей во всей красе: fake table, fake function и другие fake :)

Юнит тесты в базе данных? Вы уверены, что это Юнит тесты?

90% наших тестов проверяют отдельные методы системы: вызов конкретной процедуры и оценка выходных параметров и/или состояния бд.
Как правильней назвать такой вид автоматического тестирования?)
А в чём смысл таких тестов? Как я понял, у вас ведь тестируется по сути только логика, находящаяся в базе данных. Ведь гораздо эффективней написать функциональные или приёмочные тесты. Тогда проверяется не только логика в БД, но и вся бизнес-логика в целом.
Люблю этот вопрос)
Приёмочное, end to end, функциональное, интеграционное (или любой другой термин) тестирование это не замена, а дополнение к изолированному unit тестированию системы.
В чём проблемы:
1) Функциональные тесты намного сложнее писать. Представим, что мы проверяем бизнес-процессы интернет магазина, который безусловно интегрирован с базой данной лояльности. Но в цепочке «интернет магазин — база данных лояльности» используется ещё десяток микросервисов. Поэтому, чтобы писать такие тесты, нужно
— хорошо представлять архитектуру всей системы
— иметь эталонный набор данных во всех системах
— обеспечить что все системы находятся в валидном состоянии на тестовых контурах
2) Функциональные тесты работают существенно дольше, чем unit тесты. Например, клиент делает покупку и получает за неё бонусы. Факт покупки нужно обеспечить максимально быстро, а вот бонусы начисляются асинхронно в течение какого-то времени после покупки. Внутри системы мы можем дёргать нужные методы и сделать проверку процесса мгновенным, а что делать фронту?
3) Большой процент функционала в принципе может не иметь возможности быть покрытым функциональными тестами. Например, у нас в бд лояльности очень много логики, которая ни на какие фронты не вынесена.
Но функциональные тесты безусловно нужны, просто это отдельный уровень тестирования, который обычно осуществляется на изолированных серверах и отдельными командами. В Спортмастере мы таким также занимаемся.
Действительно довольно мало конкретики. Не пролит свет на CI/CD процессы, какая система контроля версий используется, через что и как вызываются/пишутся/отлаживаются/крутятся ваши тесты (веб? внутри субд?) и т.д.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.