Блог

Я рассматриваю два разных подхода к структурированию моих приемочных тестов. У нас есть проект Silverlight, который обращается к уровню обслуживания (я владею обеими сторонами). Из-за особенностей Silverlight тестовый код, вызывающий сборки Silverlight, должен находиться в отдельном тестовом проекте от остальных тестов, отличных от Silverlight.

1) Возьмите все критерии приемлемости, которые мы придумали, и поместите их в файлы функций. Пометьте сценарии тегами, чтобы указать среду, в которой они будут выполняться (@server, @client и т. Д.). Включите ручные тесты в файлы функций и пометьте их тегом @manual .

Плюсы: все тесты, которые записываются BAs, будут в одном месте для их просмотра и возможного редактирования

Недостатки: возможно, имеет смысл протестировать некоторые сценарии с помощью модульных тестов или интеграционных тестов, и NUnit может быть лучшим инструментом для этого, чем SpecFlow

2) Напишите критерии приемлемости для всего, но затем автоматизируйте некоторые в SpecFlow, некоторые с помощью модульных тестов, некоторые с помощью интеграционных тестов и т. Д. В SpecFlow будут только сценарии, автоматизированные SpecFlow. Мы можем поместить сценарии, которые будут проходить модульное тестирование, тестирование интеграции или ручное тестирование, в файлы компонентов, но эти сценарии фактически не будут запускать какой-либо код, они будут просто для целей документации.

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

Минусы: нам придется синхронизировать сценарии, которые не выполняются SpecFlow, с любым кодом, который их автоматизирует.

Мысли? Есть ли другой способ, о котором я не думаю? Как вы это делаете?

Я думаю, что у вас здесь два разных проекта с точки зрения тестирования.

Теоретически ваши службы могут вызываться чем-то другим, а не приложением Silverlight. Это может быть приложение HTML5, какой-либо другой контейнер MVC, написанный на Java, и т. Д. И т. Д. Поэтому я бы написал сценарии / спецификации / что у вас есть для сервисов самостоятельно.

Аналогично, у вас есть приложение Silverlight, которое может взаимодействовать с измененным уровнем обслуживания. Это будет ваш NUnit и т. Д. Тогда у вас будут дополнительные приемочные тесты в SpecFlow / Cucumber, которые будут «интеграционными» тестами, которые показывают, как все приложение будет действовать на пользователя.

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