Тестирование всех возможных вариантов взаимодействия с пользователем с использованием SpecFlow или любого другого фреймворка.

Моя установка следующая:

  • Написание клиента WPF с использованием шаблона MVVM
  • Набор модульных тестов
  • Набор сценариев SpecFlow

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

Например:

  • Пользователь нажимает «Да» -> «Загружает документ» -> «Удаляет документ» -> нажимает «Отправить».
  • Пользователь нажимает Да -> Загружает документ -> кликает отправить
  • Пользователь нажимает «Да» -> нажимает «Отправить».

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

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


person Vitalij    schedule 25.10.2012    source источник


Ответы (2)


Если вы действительно хотите создавать тестовые примеры из конечного автомата, я бы посоветовал вам изучить инструменты «Тестирование на основе моделей».

В мире .NET это позволяет сделать Spec Explorer: SpecExplorer 2010

person foobarcode    schedule 03.11.2012

Инструменты сценариев BDD обычно предназначены для включения, захвата и автоматизации диалогов между командой разработчиков и заинтересованными сторонами. То, что вы делаете, это тестирование.

Вместо того, чтобы использовать инструмент BDD, я предлагаю написать свой собственный или поискать работу других людей под «тестовой структурой», а не под тегами BDD и SpecFlow.

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

Если вы используете для этого инструмент BDD, вы обнаружите, что созданные вами сценарии действительно сложно поддерживать. Английский нельзя рефакторить так же, как код. Ваш конечный автомат может быть даже лучше при модульном тестировании (или инструменте BDD более низкого уровня — Я использую только NUnit).

person Lunivore    schedule 25.10.2012