Представьте, что у вас довольно сложная сервис-ориентированная архитектура, созданная различными компонентами. Компоненты написаны на разных языках (Java, PHP, Ruby) и взаимодействуют друг с другом по-разному (например, UI, REST API, в некоторых случаях используют некоторые таблицы DB и т. Д.).
Я пытаюсь разработать структуру тестирования интеграции для некоторого сквозного тестирования. У нас уже есть тесты на единицу / интеграцию для отдельных компонентов, но мы хотели бы построить что-то, что полностью проверяет нашу развернутую систему (в реальной среде), чтобы убедиться в функциональности (с точки зрения ожидаемого поведения отдельного компонента компоненты), и что архитектура также настроена правильно.
Первые проблемы, с которыми я столкнулся, это то, что большая часть нашего пользовательского интерфейса написана на PHP, а интеграционные тесты для UI уже написаны для него с помощью Cucumber и нескольких плагинов сверху. Структура тестирования, которую я пишу (на Java), должна запускать эти тесты функций, а затем проверять, что поведение связанных компонентов соответствует ожиданиям.
Очевидно, что я мог бы переписать тесты UI с использованием Java-дружественного компонента, такого как Selenium, но не имеет смысла дублировать усилия.
Другим решением является запуск существующих тестов с вызовом exec () в Java, ожидание возврата, возможно, анализ вывода и выполнение других действий / проверок, которые необходимо выполнить.
Внедрение существующего PHP-кода в Java не кажется жизнеспособным решением, учитывая то, как были написаны проекты.
Ни одно из описанных решений не показалось мне убедительным. В идеале было бы неплохо иметь какую-то многоязычную (и многотехнологичную) инфраструктуру интеграции, которая может подключаться к тем же тестам тестового набора, написанным на разных языках и для разных сред / компонентов.
Кто-нибудь знает какой-то инструмент или рамки, которые идут в этом направлении? Если нет, что может быть хорошим подходом к таким проблемам?
Не уверен, что это может помочь, но, возможно, взгляните на https://github.com/nablex/glue . Это язык сценариев, который я разработал с акцентом на (интеграционном) тестировании.
Он поддерживает сценарии селена из коробки, если вы подключаете https://github.com/nablex/glue-selenese и очень расширяемы.
В настоящее время я использую его у клиента с некоторыми пользовательскими расширениями для запуска устаревших скриптов, написанных в fox pro (я фактически переопределял методы fox pro … shiver ) и устаревший режим, поэтому они включаются только для устаревших скриптов, а не из новых , Я также подключил пользовательские веб-службы на основе SOAP, один из которых можно использовать для вызовов базы данных в удаленной системе, предоставляя мне широкий спектр инструментов для тестирования уровня интеграции.
Хотя язык сценариев полностью работоспособен, я все еще сдерживаю компендиум методов, доступных по умолчанию, и все еще пытаюсь позиционировать его как инструмент тестирования интеграции. Дайте мне знать, если это поможет или – нет, – почему это не отвечает вашим потребностям, всегда довольны отзывами! 🙂
PS: «Основной» класс – это хорошее место для его запуска и запуска, поскольку он содержит рабочий клиент CLI (с поддержкой точки останова!)
Вы рассматривали полное тестирование стека с чем-то вроде Jmeter?
Вы можете создавать тесты, которые работают против полностью развернутого программного обеспечения
Таким образом, вы одновременно проверяете свой ui, свою бизнес-логику и свой хранилище данных. Он также может использоваться для тестирования нагрузки.
Jmeter