Каков наилучший подход для сценариев тестирования пользовательского интерфейса модульных приложений?

Question

Хотелось бы узнать, есть ли у кого-нибудь из вас опыт автоматизации пользовательского интерфейса модульных приложений. Все приложение похоже на все типичные приложения, связанные с CRM, где в зависимости от ваших личных потребностей клиента вы просто соединяете некоторые из доступных модулей (которые были предварительно определены ранее), чтобы обеспечить все необходимые функции.

Если бы существовало «статическое» приложение, построенное из всех этих модулей, то мы могли бы протестировать его довольно простым способом, просто пройдя все определенные тестовые классы, потому что мы знали бы поведение / взаимодействия между всеми этими модулями.

Но в случае, если нам понадобится проверить поведение приложения, собрав воедино несколько его случайных частей / модулей, чтобы проверить, хорошо ли они работают, нам понадобится другой подход.

Если есть решение, какой-нибудь рекомендуемый шаблон архитектуры или что-нибудь, что может помочь мне выполнить такие тесты автоматизации (например, Selenium WebDriver)? Или такие тесты вообще можно выполнить с помощью библиотеки WebDriver?

Буду благодарен, если Вы поделитесь своими мыслями и опытом в этой области.

Answer 1

В случае, если какой-то дальнейший исследователь будет искать решение для ноу-хау для этого случая, мы можем просто установить несколько различных наборов тестов для каждого из модулей приложения, а затем мы можем проверить каждый набор на соответствие определенному условию. Если какой-то костюм не будет соответствовать этому условию, мы просто пропустим этот тест. Т.е. мы можем получить файл app bundles.json, который, скорее всего, будет содержать всю информацию о модулях приложения, а затем мы можем просто обработать этот файл для поиска модулей, которые недоступны в текущем развернутом приложении.

Посмотрите на это как на хороший пример того, как этого добиться: Знакомство с условным тестом, запущенным в TestNG

Answer 2

Я работаю в этой области, и у меня была похожая ситуация, вот что я узнал из нее:

1. Избегайте создания тестов пользовательского интерфейса, если можете. Тесты пользовательского интерфейса предназначены для проверки внешнего вида вашего приложения и все. Бизнес-логику (например, когда я меняю этот параметр, отображаемые данные должны измениться и т. Д.) Следует тестировать в модульных тестах, которые гораздо проще реализовать. Взаимодействие между модулями должно быть максимально освещено в интеграционных тестах.
2. Если у вас еще остались функциональные возможности, которые необходимо протестировать, создайте файл конфигурации, который содержит информацию о том, какие клиенты имеют какие модули включены. В вашем тесте прочитайте этот конфиг, и если тест не должен выполняться, прервите его.