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

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

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

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

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

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

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

7
acceptance-testing asp.net-mvc bdd specflow

2 ответов

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

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

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

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

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

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

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

вот пример в той же кодовой базе отображение заданного, когда, затем в примере уровня класса комментарии.

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

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

6

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

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

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

2