Что SoapUI по-прежнему делает хорошо
SOAP и WSDL. По-настоящему первоклассная поддержка — большинство современных инструментов относятся к этому как к чему-то второстепенному, если вообще поддерживают.
Сборка сложных сообщений. Глубокая работа с XML и проверки по нему — ровно то, что нужно корпоративной интеграции.
Мок-сервисы. Возможность поднять фейковый эндпоинт, под который можно разрабатывать, — встроенная.
Если в вашей работе много SOAP, внимательно отнеситесь к тому, от чего вы откажетесь. Охват здесь действительно серьёзный.
Почему команды всё равно ищут замену
| Рабочий процесс, заточенный под десктоп | Файлы проекта лежат на чьей-то машине, и их неудобно ревьюить. В pull request сложно понять, кто и что изменил. |
| Трудности с пайплайном | Headless-запуск возможен, но редко бывает приятным. Отчёты оказываются не там, где остальные отчёты CI. |
| Удобство работы с REST | Модель создавалась под SOAP. REST работает, но ощущается как что-то привнесённое извне. |
По каким критериям сравнивать альтернативы SoapUI
| Критерий | SoapUI | TestSprite |
|---|---|---|
| Охват протоколов | SOAP, WSDL, REST, JMS и другие | REST API на работающем сервисе |
| Где живут тесты | Файлы проекта, редактируются в десктопном клиенте | В проекте, описаны на обычном языке |
| Как строится покрытие | Каждый запрос и каждую проверку кто-то собирает вручную | Генерируется из спецификации или по результатам прохода обнаружения |
| Сессии и состояние | Свойства и скрипты, которые вы поддерживаете сами | Auto-Authentication и Dynamic Variables |
| Порядок и очистка | Порядок тест-кейсов плюс скрипты teardown | Автоматически выведенный порядок и Auto-Cleanup |
| Встраивание в пайплайн | Headless-раннер, отдельная отчётность | Запуск по изменению, результаты в pull request |
Механика работы с состоянием описана в документации по тестированию API.
Что проверить перед переходом
Проведите инвентаризацию: сколько у вас на самом деле SOAP. Команды часто обнаруживают, что набор на девяносто процентов состоит из REST, а SOAP — это горстка legacy-эндпоинтов, которых никто не трогал годами. Если это ваш случай, миграция гораздо меньше, чем кажется, а оставшийся SOAP может остаться там, где он есть.
Если SOAP действительно много, не переезжайте ради удобства. Охват важнее.
Как оценивать любой из вариантов
Сломайте что-нибудь намеренно. Внесите настоящую регрессию — например, сохранение, которое больше ничего не сохраняет, — и посмотрите, что сообщит каждый кандидат. Упадёт ли тест, назовёт ли падение реальное расхождение и сможет ли тот, кто будет это чинить, начать прямо с такого вывода, не восстанавливая всю картину заново. Инструмент, который сообщает об успехе на прогоне, так и не дошедшем до своих проверок, провалил единственный тест, который имеет значение.
Как разделить набор тестов до переезда
Миграция, которая работает, почти никогда не делается разом, и разделить набор проще, чем кажется: SOAP и REST редко переплетаются в одном тесте.
Начните с того, что пометьте каждый тест-кейс по протоколу. Большинство команд находит три группы: настоящий SOAP к legacy-сервисам, REST к более новым сервисам и небольшую часть, которая затрагивает и то и другое, потому что сценарий охватывает разные поколения. Первая группа остаётся на месте и перестаёт быть причиной держать там весь набор. Вторая переезжает. Третью стоит разобрать поштучно — часто она распадается на два теста, которые объединили ради удобства, а не по необходимости.
Если начать с разметки, у миграции появляется видимый конец, а это и есть разница между проектом, который завершается, и проектом, который через год всё ещё сделан наполовину.
С чего начать
Терминал
npm install -g @testsprite/testsprite-cli
testsprite setup
Если вы не хотите ничего устанавливать, то же самое делает дашборд. Всё остальное, что умеет командная строка, есть в репозитории CLI.
GitHub App — это вебхук, который вы настраиваете в дашборде TestSprite. Он слушает событие деплоя, которое ваш пайплайн уже генерирует, поэтому в репозитории ничего не меняется.
GitHub Actions помещает шаг внутрь вашего собственного workflow, настройка — из терминала.
Что TestSprite закрывает на стороне REST
Всё, что делала REST-часть вашего набора, но с рабочим процессом, подогнанным под пайплайн, а не под десктоп. Кейсы живут в проекте, описываются на обычном языке и дорабатываются так же, поэтому изменение может проверить второй человек.
Работа с состоянием поставляется как часть продукта: Auto-Authentication, Dynamic Variables, Dependency Chains и Auto-Cleanup — то, что в SoapUI представляет собой свойства, шаги передачи данных, порядок тест-кейсов и скрипты teardown, которые вы поддерживаете сами.
Прогоны запускаются вашим деплоем или из вашего собственного workflow, а результаты приходят комментарием в pull request. Ваша работа с SOAP остаётся там, где она нормально поддерживается, а у миграции появляется видимый конец — вместо состояния «сделано наполовину» через год.
Поддерживает ли TestSprite SOAP?
Фокус — на REST API к работающему сервису. Если в наборе много SOAP, оставьте то, что нормально с ним работает, а этот инструмент используйте для REST-поверхности.
Можно ли конвертировать проекты SoapUI?
Используйте их как опись того, что уже есть, а не как то, что нужно конвертировать. Ценное содержимое — это список эндпоинтов и те проверки, которые были людям важны.
А как же мок-сервисы?
Это отдельная возможность, и её стоит сохранить, если вы на неё полагаетесь. Моки и проверка — разные задачи.
Стоит ли взять Pro вместо перехода?
Если претензия к функциям — возможно. Если претензия в том, что рабочий процесс не вписывается в пайплайн, тариф этого не изменит.
Как запускать оба инструмента во время перехода?
Направьте их на разные части поверхности и запускайте оба из CI. Переключаться в один шаг нет никакой необходимости.
Проверьте, какая часть вашего набора на самом деле относится к SOAP.
Альтернатива SoapUI имеет смысл, когда десктопный рабочий процесс перестаёт вписываться в ваш пайплайн, а большинство наборов оказываются в основном REST. Оставьте SoapUI для настоящей работы с SOAP, а REST-поверхность перенесите туда, где она соответствует тому, как вы выпускаете релизы.