имеющиеся автотесты API, мол, смотри как у нас сделано.
В этих автотестах сделано так. Из базы берётся текст запроса и этим стреляют в API. Полученный ответ сверяют с ответом, когда-то ранее записанным в базу.
API отвечает за создание отчётов, и есть отчёты, которые подбивают статистику за полгода-год, так и те, что формируют данные за вчера.
С одной стороны, если надо протестировать API, то, наверное, это самое простое решение.
С другой стороны, я как ручной тестировщик, помню, что такое эффект пестицида, и что для его избегания нужно постоянно варьировать тестовые данные. Тут же получается, что тестовые данные меняются хорошо если раз в полгода.
Я думаю о том что бы каждый раз при запуске автотестов данные должны бы подтягиваться из разных, не зависящих друг от друга источников, что бы формировать тестовый эталонный набор, с которым проводить сверку.
Я помню, что самые худшие автотестеры вырастают из хороших тестеров, поэтому прошу совета.
Как правильно?
Подход описанный выше звучит вполне нормально. Особенно, если он давно применяется, то ответить на вопрос о его адекватности просто - проверьте пропущенные баги. Много их было? Пропущены они были из-за того, что данные одинаковые? Насколько сильно улучшила бы вариация данных отлов проблем?
Тимур, тоже присоединюсь с ответом. Выясните точную цель автотеста. Это было "покрыть все" или это регрессионка с целью "просто проверить, что не отвалилась функция". Сами понимаете, для разных целей будут разные наборы данных. Для последнего варианта именно тот, который вы описали - "проверить только что-то и убежать" 😊
Обсуждают сегодня