Как организовать тесты Webdriver

Question

Я хочу создать несколько тестов Webdriver для тестирования моего веб-приложения на Java, но я не уверен, должны ли они жить в другом проекте или в моем проекте веб-приложения.

Я также хочузапускать эти тесты Webdriver с моего CI-сервера Hudson при каждой фиксации в моем SVN-репозитории - будет ли это стандартной практикой?

Не думаю, что это имеет большое значение, но мне хотелось бы знать, что делают другие люди?

Answer 1

Хорошей практикой является разделение вашего проекта и тестов Selenuim, особенно если вы планируете запустить их в Hudson. Это связано с тем, что такие тесты будут выполняться в течение длительного времени, и вы хотите, чтобы сборка работала быстро.

Таким образом, вы должны создать отдельный проект с тестами и запустить его после завершения основного проекта - все это можно настроить в Hudson. А вы можете настроить свой проект для сборки после каждого коммита, однако вам следует прочитать соответствующую документацию Hudson

Answer 2

Если вы создаете тесты для приложения ASP.NET с элементами управления, которые повторно используются для разных страниц, возможно, имеет смысл создать класс для каждого элемента управления, а не для каждой страницы.Но обычно вы хотели бы сделать каждый класс специфичным для страницы.И следите за тем, чтобы на вашей странице были сервисы / функции, а не то, что происходит в коде.

Это хороший обзор.http://code.google.com/p/selenium/wiki/DesignPatterns

Answer 3

У нас есть большое корпоративное приложение, написанное на Java и Gwt, поэтому на клиенте много JS.

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

Теперь мы приступили к завершенному тестированию сценария сценариев использования с помощью cucumber + watir + webdriver.Тесты написаны на Ruby и Gherkin (огуречный DSL) и выполняются на нашем приложении.Мы интегрировали это с Hudson, и у нас есть хорошие скриншоты для любых ошибок (и скоро также .avi)

До сих пор специалисты QA и BA были энтузиастами, и усилия по разработке уже окупились, учитывая экономию на повторном тестировании функций, сравниваемых вручнуюзапустить люкс и пойти на кофе.;)