Каков наилучший подход для написания тестов автоматизации для веб-приложений JAva? - PullRequest
2 голосов
/ 04 июня 2009

Я обнаружил, что для тестирования автоматизации Java лучше использовать Cruise Control (java), JUNIT (инфраструктуру тестирования java) вместе с Watij. Любые дальнейшие предложения, пожалуйста. Любой, кто успешно интегрировал эти инструменты и какие ограничения для этого найдены.

привет

Ответы [ 3 ]

2 голосов
/ 04 июня 2009

Обычно мы пытаемся протестировать приложение на 3 уровнях:

  • Юнит-тесты с JUnit. Для этого мы следуем шаблону Dependency Injection и используем при необходимости фиктивные объекты (основанные на платформе JMock).
  • Интеграционные тесты. Они также основаны на JUnit, но не используют фиктивные объекты и тестируют различные уровни приложения, например, запись в базу данных. Для получения базовых данных мы следуем шаблону Object Mother .
  • Приемочные испытания, для этого мы используем Selenum.

Для автоматизации тестирования и непрерывной интеграции наши проекты построены с использованием Maven и Hudson. Одним из улучшений, которые мы рассматриваем в настоящее время, является использование Groovy вместо Java для тестов.

Некоторые из проблем, которые нам пришлось решить: создание базовых данных при настройке тестового набора (на основе шаблона Object Mother), организация тестовых наборов, так как все тесты могут занять много времени, имея дело с дублированием в тестовом коде и много возиться с Maven и Selenuim, но это определенно того стоит в долгосрочной перспективе.

1 голос
/ 04 июня 2009

Один из моих коллег - большой поклонник Watir , который, как мне кажется, похож на Watij. Мне нравится Селен , и в последнее время я планирую поиграть с Теллур .

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

Ограничения на функциональное тестирование веб-приложения:

В то время как вы можете сказать пользователю, чтобы он щелкнул «первый элемент в меню слева», сказать компьютеру сделать то же самое не так просто. Среды тестирования веб-приложений не могут смотреть на экран и легко различать, какие элементы на странице составляют меню. Им нужно больше деталей о том, с каким элементом взаимодействовать, а это, в свою очередь, требует некоторых знаний о том, как устроена HTML-страница. И как страница меняется, так и тесты могут.

Когда каждое небольшое изменение в одной части страницы нарушает тесты в других, не связанных между собой частях страницы, эти тесты называются «хрупкими». Чтобы убедиться, что тесты более стабильны, требуется некоторый опыт, как и при обычном модульном тестировании. Например, используйте идентификатор элемента или имя для ссылки на элементы на странице, а не на их полный XPath (может быть длинным и нечитаемым, а также хрупким) или их текстовое содержимое (если оно может измениться).

0 голосов
/ 04 июня 2009

Нам нравится использовать WATIR для функционального тестирования веб-приложений. Это пакет автоматизации браузера для Ruby. Легко учиться, и мы не столкнулись с какими-либо препятствиями после написания многих тестовых случаев

...