BDD-тестирование с использованием UI-драйвера (например, Selenium для веб-приложения)

Мы сделали это для приложения C#, используя инструмент тестирования WPF (WipFlash) и написав NUnit. тесты в стиле BDD.

e.g.

Given.TheApplicationWindowIsOpen();
When.I.Press.OKButton();
The.Price.ShouldBeCalculated();

Излишне говорить, что нам пришлось самим кодировать большую часть DSL. Но это решение становится понятным для бизнеса/клиента.

Попробуйте использовать SpecFlow с WatiN: (я не уверен, что вы используете здесь .NET)

http://msdn.microsoft.com/en-us/magazine/gg490346.aspx

Для веб-тестирования вы можете попробовать WebDriver. Команда Selenium в данный момент занята интеграцией WebDriver. Саймон Стюарт из Google, создавший WebDriver, записал здесь о том, как он работает по-другому в Селен.

WebDriver использует разные технологии для каждого браузера. Для Internet Explorer WebDriver использует автоматизацию пользовательского интерфейса Microsoft — ту же технологию, на которой WipFlash @Brian Agnew упомянутый основан. Это максимально близко к тому, чтобы притворяться, что вы нажимаете кнопки. Блог Саймона показывает, почему этот подход может быть более мощным, чем решение Selenium Javascript.

WebDriver доступен на сайте Selenium, но еще не полностью реализован как часть Selenium.

Для BDD и любых тестов, основанных на сценариях использования, важно иметь возможность сообщить, что делает тест. Проблема со многими наборами тестов заключается в том, что после написания никто точно не знает, что именно делает тест. Это будет возникать очень часто, если вы пишете на неспециализированном языке. Специализация не обязательно означает особый язык, но достаточно абстракции в одном языке, чтобы было понятно, что происходит.

Например, многие тесты имеют код, который выглядит так (псевдокод, я не буду выбирать какой-то конкретный фреймворк):

object = createBrowser()
response = object.gotoURL( "http://someurl.com" );
element = response.getLink( "Click Here" );
response = element.doClick();

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

GotoURL http://someurl.com/
Click link:Click Here

Selenium и его макросы или интерфейс в этом отношении все еще находятся на довольно низком уровне. Если вы их используете, то по крайней мере создайте вокруг них несколько оберток.

Конечно, вы также можете использовать продукт под названием TestPlan. Он имеет Selenium в серверной части и предоставляет высокоуровневый API, а также собственный язык для тестирования. Он также выходит за рамки только Интернета и включает электронную почту, FTP и т. д. Вышеприведенный образец языка представляет собой фрагмент TestPlan.

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

Книга RSpec поддерживает двухуровневый цикл с приемочными тестами (или сценариями). ) сначала написаны (в основном на Cucumber), а модульные тесты написаны (на RSpec) во внутреннем цикле, более похожем на традиционный TDD.

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

Тесты, тестирующие все приложение через пользовательский интерфейс, сложнее воспроизвести, и они имеют тенденцию быть медленнее и более хрупкими, чем модульные тесты.

На самом деле вы можете сделать и то, и другое - сделать интерфейс драйвера, ориентированный на пользователя (независимо от графического интерфейса/технологии/импл). Затем вы можете написать UIDriver и APIDriver и выбрать драйвер для запуска определенного теста. Работа через пользовательский интерфейс обычно происходит медленнее (вне процесса элемент управления перерисовывается, но каким-то образом изначально создается более высокий уровень уверенности). Работа через API намного быстрее (в проце, легкая установка-разборка).

Хитрость здесь заключается в том, чтобы отделить «что» от «как». В противном случае вы получите ObscureTests и высокое обслуживание тестов. Убедитесь, что основное внимание уделяется тестированию, а не автоматизации.