Прежде всего, просто некоторые разъяснения. Когда вы говорите «4) Модуль сервисов Flex, упакованный как SWC», вы подразумеваете, что библиотека сервисов Flex, которую я собираю, загружается как RSL. Это важная разница, чем написание сервисов в качестве модуля времени выполнения, потому что последний может (и обычно будет) создавать экземпляр самого контроллера сервисов и распределять подключение сервисов к другим модулям. Ваша альтернатива, просто библиотека, которую вы встраиваете в каждый модуль, означает, что все они создают свой собственный экземпляр сервисного контроллера. Вам лучше поместить логику сервисов в модуль, который приложение может загрузить до загрузки других модулей, и управлять движением сервисов между ними.
Например.
Application.swf - запускает, инициализирует контейнер IoC, загружает Services.swf, внедряет любые необходимые ему зависимости
Services.swf загружает, устанавливает соединение с сервером, управляет необходимым набором сервисов
Application.swf добавляет управляемые экземпляры из Services.swf в свой контейнер (используя некоторую форму контекстной осведомленности для предотвращения конфликтов)
Application.swf загружает ModuleA.swf, внедряет все необходимые зависимости
Модуль ModuleA.swf загружает (имеет перечисленные зависимости, полученные из Services.swf, внедренные), использует эти зависимости для связи со службами, которые ему необходимы.
Тем не менее, придерживаясь вашей нынешней структуры, я отвечу на ваши вопросы максимально точно.
Что вы хотите проверить в интеграции? То, что ваши услуги там и возвращают то, что вы ожидаете, я собираю. Таким образом, если вы используете удаленные объекты в BlazeDS, вы можете написать тесты, чтобы убедиться, что вы можете найти конечную точку, найти каналы, место назначения (назначения), что все удаленные методы возвращаются, как и ожидалось. Команда сервера проверяет хранилище данных (от них до БД и обратно), но вы проверяете, что договор между вашим клиентом и сервером все еще выполняется. Этот контракт предназначен для любых допущений - таких как объекты значений, возвращаемые в полезных нагрузках, существующие удаленные методы и т. Д. И т. Д.
(см. № 4 ниже). Тесты должны быть в их модуле, однако я бы сказал, что у вас действительно должен быть модуль для обслуживания (вместо библиотеки, как я предлагал выше). В любом случае, да, все же разверните артефакты тестирования на локальном веб-сервере (используя Jetty или какой-либо другой) и убедитесь, что цель интеграционных тестов зависит от используемого вами упаковщика WAR.
Я считаю, что некоторые разработчики обмениваются пользовательским интерфейсом / функциональным тестированием с интеграционным тестированием. Несмотря на то, что вы действительно можете выполнять их вместе, в Flex все еще есть место для автоматизированных интеграционных тестов, где загружается веб-сервер и проверяются основные службы, чтобы убедиться, что они существуют и возвращают то, что требуется. Для пользовательского интерфейса / функциональных тестов Adobe поддерживает хороший набор ресурсов: http://www.adobe.com/products/flex/related/#ftesting. Для интеграционных тестов, как я уже говорил,
Интеграционные тесты должны иметь свою собственную цель, которая зависит от упакованного проекта WAR.