Comments 7
Довольно монструозно выглядит. А это действительно все надо? Хотелось бы чтобы тесты были простыми, но эффективными.
И если речь заходит об архитектуре - то статья начинается где-то с середины. Я ожидал, что вначале будет про тестирование черного и белого ящика. Как пример могу привести - тестирование api через rest вызовы и тестирование того же api с прямым вызовом бизнес слоя.
Далее собственно про сами слои (есть ui, бизнес логика, и хранилище данных, могут быть внешние системы). Для каждого слоя характерны те или иные паттерны.
Далее интересно было бы узнать - что надо тестировать, а что нет. Например нет смысла тестировать БД как таковую. Она уже оттестирована разработчиками БД. Есть смысл тестировать БД в связке с бизнес логикой.
Следующим пунктом интересно было бы увидеть систематизированную информацию о том, как обеспечить повторяемость тестов. Дата генерация конечно хорошо, но перед повторным запуском тестов - надо все это откатить.
И далее уже расписывать паттерны детальней.
И самая интересная часть для меня - это тестирование взаимодействия с внешними системами. Эта часть ломается чаще всего по моему опыту. Но вместе с тем там крайне хрупкие тесты.
Хорошая статья, все достаточно понятно описано, применяю аналогичные паттерны в своей работе!
Вопрос к автору: представьте, что изначально у вас проект для тестирования API, потом вы решили добавить туда ещё и UI тесты, в которых для подготовки данных вы хотите переиспользовать готовые API Steps, будете ли вы наследоваться от первого тестового проекта или будете реализовать похожие Steps, но уже в проекте с UI тестами?
Привет. Шаг от шага все таки наследовать плохая практика (мое ИМХО). Мой подход в этом плане такой: я выношу какие то действия в шаге в отдельные функции и вот их уже вызывать в разных шагах. На мой взгляд также можно в UI тестах использовать готовые API шаги без наследования. Условно говоря есть UI шаг "я добавил заказ". Потом идет шаг проверить API ответ для этого я просто использую API шаг: "я проверил что наш заказ есть в полученном API запросе заказов".
Вообще в практике если позволяет приложения я придерживаюсь концепции для UI тестов: "один тест одна страница" . то есть если мой UI тест проверяет создание заказа то он визуально проверяет только этот экран - остальное проверяется через API. Тоже самое если я проверяю страницу списка заказов я пред настройку делаю через API и проверяю только что визуально я вижу те заказы что до этого создал мой тест через API )
В общем вы все правильно описали!
Но в идеале хорошо приводить примеры кода тех или иных частей. И как это взаимодействут друг с другом.
ЗЫ вот у нас в поекте есть все части что вы упомянули. Вообще все. Мы делали UI тесты, а все остальное приросло по ходу и API и DB. Как итог API + DB вынесли в отдельный модуль и теперь это используется в 5ти других проектах.
В этой статье я делаю упор на теорию без примера. Возможно в будущем если будет время и я перепишу какой то свой фреймворк (выпилив от туда конф. инфу) как пример для этой статьи потому что тут надо шарить весь рабочий репозиторий а не куски кода, чтобы были видны взаимосвязи (мое имхо конечно же).
ПС: у меня тоже есть проект в котором генерация тестовых данных (пользователей и других сущностей) вынесена в отдельный микросервис с апи ручкой. Как раз таки сделано это для того чтобы разные автоматизированные проекты могли их дергать. Так что тут я соглашусь что если есть необходимость и возможность надо выносить.
Странно, для новичков слишком много абстракции, нет примеров паттернов, например checker, steps, а опытные и так это знали, вообщем я немного в замешательстве
Паттерны автоматизации и архитектура автотестов