Если задаться вопросом о том, можно ли применять сразу несколько фреймворков на одном проекте, то однозначного ответа достичь будет проблематично.
Но, скорее всего, ответ будет положительным, так как настоятельным образом рекомендуется работать сразу с несколькими фреймворками, которые идеально подходят под несколько целей.
На практике настроить одновременное использование нескольких фреймворков несложно.
Далее детально разберем, когда все же подобное использовать нужно, а при каких обстоятельствах от него стоит отказаться.
Отсутствие универсального способа использования
Настоятельным образом рекомендуется применять инструменты и прочее ПО, которые идеально подходят под конкретные цели.
Например, для модульных тестов не подойдет то программное обеспечение, которое используется для тестирования ключевых изменений.
Модульные тесты могут напрямую обращаться к внутренним параметрам и методам программного кода ПО, а вот тесты ключевых изменений взаимодействуют исключительно с «живыми» версиями продукта (через внешнего пользователя или сервис).
Все это значит, что каждая такая группа проверок требует своего персонального решения, а решения, в свою очередь, базируются на применении определенного ПО и фреймворков!
Простой пример, Behave — это распространенный BDD-фреймворк под язык программирования Python.
Авторы создают тест-кейсы на основе языка программирования Gherkin с большим перечнем Python-функций в качестве определенного набора тестовых шагов.
Все тест-кейсы на Gherkin максимально интуитивно читабельны и легки для понимания, а значит, хорошо подходят для проверки высокоуровневых поведений по примеру взаимодействия с веб-страницами.
Но, в то же время, BDD-фреймворки добавляют некоторую сложность, и могут препятствовать созданию необходимых модульных тестов.
Модульные тесты по своей технической составляющей крайне близки к программному коду и располагаются на самом низком уровне, так как напрямую вызывают продуктовый код ПО.
Фреймворк PyTest идеально подойдет для процесса модульного тестирования.
И совершенно наоборот — все тесты ключевых изменений можно создавать на «чистом» PyTest, но Behave предоставляет более естественную архитектуру для процесса описания тестовых фич.
Из этого логически следует, что самым оптимальным вариантом станет применение разделительных решений для разнообразных видов проверок.
Сочетание фреймворков
Использование одного или двух репозиториев
Если вы работаете на проекте, где осуществляются сразу несколько тест-решений, появляется следующая дилемма — где лучше всего размещать программный код?
Должен он находится в том же репозитории, что и код проекта, или отделу разработки стоит выводить проверки в отдельные репозитории?
На данный вопрос нет одного правильного ответа, так как всегда нужно учитывать следующие факторы.
- Модульные тесты обязательно должны находится там же, где и программный код ПО, который его проверяет. Каждый модульный тест зависим от кода. Они должны создаваться на том же языке. Всегда при рефакторинге кода продукта нужно выполнять модульные тесты;
- Используемые тесты ключевых изменений можно располагать там же, либо же в отдельном репозитории. Рекомендуется добавлять их в то же место, что и программный код проекта, если они, конечно, написаны на одном языке и если абсолютно весь тестируемый код располагается в этом же репозитории. При такой ситуации, контроль версий тестов проводится вместе с проверяемым продуктом. В ином случае, рекомендуется сохранять тесты ключевых изменений в отдельном репозитории. Разноязычные репозитории программирования крайне сложно поддерживать, и процесс контроля версий для ПО с несколькими репозиториями должен выполняться по-другому.
Заключение
Резюмируя все вышесказанное, стоит отметить тот факт, что различные тест-инструменты и фреймворки могут (и должны) предназначаться для разных целей и задач.
Нет универсального сочетания для решения всех задач. Просто необходимо всегда подбирать правильные инструменты для решения тех задач, которые компании по тестированию ПО могут решить «здесь и сейчас».
Оставить комментарий