Как выбрать между различными типами тестов с помощью SpecFlow, Cucumber или другой среды приемочных испытаний BDD?

Question

Я смотрю на примеры SpecFlow, и это образец MVC содержит несколько альтернатив для тестирования:

• Приемочные испытания, основанные на проверке результатов, полученных контроллерами;
• Интеграционные тесты с использованием MvcIntegrationTestFramework;
• Автоматизированные приемочные испытания с использованием селена;
• Ручные приемочные испытания, когда тестеру предлагается подтвердить результаты вручную.

Должен сказать, что я очень впечатлен тем, насколько хорошо написаны примеры SpecFlow (и мне удалось запустить их в течение нескольких минут после загрузки, просто пришлось настроить базу данных и установить сервер Selenium Remote Control). Глядя на тестовые альтернативы, я вижу, что большинство из них дополняют друг друга, а не являются альтернативой. Я могу думать о следующих комбинациях этих тестов:

• Контроллеры тестируются в стиле TDD, а не с использованием SpecFlow (я считаю, что тесты типа Given / When / Then должны применяться на более высоком сквозном уровне; они должны обеспечивать хорошее покрытие кода для соответствующих компонентов;
• MvcIntegrationTestFramework полезен при запуске интеграционных тестов во время сеансов разработки, эти тесты также являются частью ежедневных сборок;
• Несмотря на то, что тесты на основе Selenium автоматизированы, они медленные и в основном должны запускаться во время сеансов QA, чтобы быстро проверить, что на страницах и в рабочем процессе сайта нет сломанной логики;
• Ручные приемочные испытания, когда тестировщику предлагается подтвердить достоверность результатов, в основном предназначены для проверки внешнего вида страницы.

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

Заранее спасибо.

Answer 1

Это все поведение.

Учитывая определенный контекст, когда событие происходит (в пределах определенной области), тогда должен произойти некоторый результат.

Область действия может быть целым приложением, частью системы или отдельным классом. Даже функция ведет себя таким образом, с вводом в качестве контекста и выводом в качестве результата (вы также можете использовать BDD для функционального языка!)

Я склонен использовать каркасы модулей (NUnit, JUnit, RSpec и т. Д.) На уровне класса или интеграции, потому что аудитория техническая. Иногда я документирую Данные / Когда / Затем в комментариях.

На уровне сценария я пытаюсь выяснить, кто на самом деле хочет помочь в чтении или написании сценариев. Даже заинтересованные стороны могут читать текст, содержащий несколько точек и скобок, поэтому главная причина наличия естественной языковой структуры, такой как MSpec или JBehave, заключается в том, хотят ли они сами писать сценарии или показывать их людям, которые действительно будут отталкиваться от точек и скобки.

После этого я смотрю, как фреймворк будет играть с системой сборки, и как мы дадим возможность читать или писать соответствующим образом заинтересованным сторонам.

Вот пример, который я написал , чтобы показать, что вы можете делать со сценариями, использующими простые DSL. Это просто написано в NUnit.

Вот пример в той же кодовой базе , показывающий «Дано, Когда, Тогда» в комментариях к примеру на уровне класса.

Я абстрагируюсь от шагов позади, затем помещаю экраны или страницы за ними, затем на экранах и страницах, которые я называю любой системой автоматизации, которую я использую - это может быть Selenium, Watir, WebRat, Microsoft UI Automation и т. Д.

Пример, который я привел, сам по себе является инструментом автоматизации, поэтому сценарии демонстрируют поведение инструмента автоматизации посредством демонстрации поведения поддельного графического интерфейса на случай, если это запутает. Надеюсь, это поможет в любом случае!

Answer 2

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

Так что это компромисс,это может быть различным для каждой ситуации (поэтому мы предоставили альтернативы).

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