Есть ли методика для интеграционного тестирования Java приложений?
Есть крупное Java Web приложение.
Интеграционные тесты построены с применением TestNG, Maven и его плагинов (Failsafe + плагины для БД и запуска JBoss).
Всё тестирование вынесено в отдельный модуль и запускается через мавен, который разворачивает окружение (разворачивает базы, запускает сервер, деплоит в него приложение), после уже работают сами тесты через TestNG.
Проблема в том, что изначально всё выглядело очень структурированно и просто, но со временем тесты разрастались, и теперь добавление новых тестов уже не такая приятная и быстрая задача, так как у тестов стало много зависимостей и различных условий их выполнения. Всё упирается в то, что у приложения есть основной бизнес процесс, который и моделируется тестами, данный процесс проходит красной нитью через всё тестирование с различными ответвлениями, и различным набором входных данных. Есть ли хорошая методика или примеры, каким образом можно упростить или структурировать данный подход? Спасибо.
вы селениумом пользуетесь и если нет почему? хочу понять чем обусловлен ваш подход.
приведите пример тестового сценария без деталей. вы описываете проблему так как ее видите вы (точнее описываете то, во что сейчас уперлись), и скорее всего получите ответы в контексте вопроса. но возможно нужно пересмотреть весь подход. отойти от стенки в которую вы уперлись и посмотреть а туда ли вы двигаетесь, например.
У нас приложение к примеру, не позволяет прямого доступа к любому состоянию системы, и некоторые сценарии приходится проводить от начала до конца, возвращаться назад и проводить следующий сценарий. Чтобы сократить время выполнения, я делаю обход дерева состояний в ширину. Стараясь захватить "еще что нибудь раз я уже сюда пришел". И вдоль одной такой тестировочной цепочки тесты связаны между собой. Одна цепочка представляет собой testsuite. Они разбиты на тесты в принципе ради того чтобы легче было понять в каком шаге и что пошло не так. (да говорят что тесты должны быть независимыми, но это зависит от конкретной ситуации, всякий подход имеет право на существование https://testautomationpatterns.wikispaces.com/CHAI... )
Все тесты у нас разбиты на контексты, контексты на testsuites. Наборы тестов и сами тесты выполняются в алфавитном порядке. Новые тесты я вставляю в те места где по бизнес логике находятся другие тесты. Сами тесты построены модульно по принципу page object, так что склепать новый тест дело не сложное. Когда обход основных состояний сделан, я добавляю сценарии связывающие максимально крайние точки. Пойти по самому нетоптанному пути, выбрать максимально отличную комбинацию параметров. (своебразное комбинаторное/парное тестирование на эвристике вместо математики.)
Потом обязательно следите что является самой частой причиной отказа системы, и уделяйте этим областям внимание, систематическое тестирование, и равномерное покрытие не всегда оправданы. Оптимизируйте тестовые сценарии, подумайте как с проложить сигнальный провод так, чтобы под сигнализацией оказалось максимальное количество предметов. Представьте себе, вам сказали мы можем выполнять только один тест, какой бы вы выбрали? Такие размышления приведут вас туда куда надо.
Помоему я отклонился от темы :)
Простой
Простой
