Задача
На моем рабочем месте мы пытаемся найти наилучший способ создания автоматизированных тестов для почти полностью основанного на JavaScript приложения для интрасети. Прямо сейчас мы застряли, пытаясь найти хороший компромисс между:
- Код приложения в повторно используемых и вложенных компонентах графического интерфейса.
- Тесты, которые легко создаются командой тестирования
- Тесты, которые можно записать один раз, а затем автоматизировать
- Тесты, которые не ломаются после небольших косметических изменений на сайте
Выражения XPath (или другие возможные выражения, такие как селекторы jQuery), наивно сгенерированные из Selenium-IDE, часто не повторяются и очень хрупки. И наоборот, наличие кода JS создает специальные уникальные значения идентификаторов для каждого важного DOM-элемента на странице ... ну, это его собственная головная боль, осложненная повторно используемыми компонентами графического интерфейса и идентификаторами, которые должны быть согласованными при повторном тестировании бежать.
Какие успехи были у других людей с такими вещами? Как вы проводите автоматическое тестирование на уровне приложений расширенного интерфейса JS?
Ограничения
- Мы используем JavascriptMVC 2.0, надеюсь, скоро 3.0, чтобы мы могли перейти на jQuery 1.4.x.
- Люди, которые занимаются тестированием, в основном обучены использованию Selenium IDE для прямой записи.
- Испытательные лидеры предпочитают уникальный HTML-идентификатор страницы для каждого элемента, активируемого нажатием кнопки на странице ...
- Обучение тестировщиков написанию или изменению специальных выражений (например, указание им, какие имена классов HTML являются важными точками ветвления) не требуется.
- Мы пытаемся сделать повторно используемые компоненты javascript, но это означает, что очень немногие компоненты GUI могут рассматривать себя (или что они содержат) как уникальные.
- Некоторые из наших компонентов уже используют значения HTML ID в своей работе. В любом случае, я бы хотел избежать этого , но это усложняет идею тестирования на основе идентификаторов.
- Возможно добавление пользовательских средств (таких как построитель локатора или новый метод локатора) к использованию тестеров установки Selenium-IDE.
- Почти все, что происходит, происходит в пределах одной "загрузки страницы" с точки зрения обычного браузера, даже когда элементы сохраняются
Текущие мысли
Я рассматриваю систему, в которой пользовательский локатор-конструктор (код javascript) для Selenium-IDE будет общаться с нашим кодом приложения во время записи тестером. Таким образом, наше приложение становится частично ответственным за генерацию в основном гибкого выражения (XPath или jQuery) для любого данного элемента DOM. Несмотря на то, что этого можно избежать, требуя дополнительной подготовки для тестировщиков, я беспокоюсь, что это может быть слишком обдуманным делом.