Как / над чем насмехаться в BDD

Я знаю, что одним из намерений Дэна Норта при разработке BDD было отодвинуть словарный запас от сложности тестовой области. Однако при реализации подхода «снаружи-внутрь», похоже, нам все еще требуется некоторое понимание имитационного поведения (или заглушенного поведения, если хотите). Норт предлагает в этом видео, что если я начну с самых внешних объектов домена и продвинусь внутрь, я издеваюсь соавторов, когда я их обнаруживаю и позже заменяю подходящими реализациями. В итоге я получаю набор сквозных тестов.

В этом сообщении в блоге Мартин Фаулер, похоже, определил два лагеря TDD: «классический TDD», который по возможности использует реальные объекты, а при необходимости - имитацию, а также "mockist TDD", который в большинстве ситуаций предпочитает имитировать. Он считал, что BDD склоняется к последнему. То есть, что в конце разработки функции подход «mockist» оставит имитацию в реальных тестах (извините за использование этого слова в обсуждении BDD).

Честно говоря, обоим материалам уже много лет, и, возможно, все стало проясняться по мере того, как BDD развивался по линии между применением на уровне единицы и уровнем принятия.

Но мой вопрос к сообществу сводится к следующему: когда моя история будет завершена, какой степени сквозного тестирования должны быть мои сценарии на самом деле? North объясняет, что BDD требует абстракций. Например, когда я тестирую поведение входа в систему, мои сценарии подробно описывают, что означает процесс входа в систему. Однако, когда я выполняю какой-либо другой сценарий, который требует, но не входа в систему, я не хочу повторять эти шаги снова и снова. Мне нужна простая абстракция, которая просто говорит: «Если я вошел в систему», чтобы я мог выполнить другое свое поведение.

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

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


person Ryan Nelson    schedule 01.05.2012    source источник


Ответы (3)


Я думаю, что главное - сосредоточиться на BDD - поведении.

На данный момент я склонен игнорировать элементы пользовательского интерфейса и высмеивать слои персистентности - после всех этих дней в этих слоях практически нет бизнес-логики (мы склонны просто привязывать объектные модели непосредственно к пользовательскому интерфейсу или БД, используя уже существующие и тщательно протестированные фреймворки).

В качестве примера, в недавнем (простом) приложении WPF, которое я создавал: приемочные тесты используют ViewModel в качестве точки входа / выхода приложения - и все, что находится в репозиториях данных, было имитировано. Все правила и логика приложения существовали где-то посередине - и на самом деле это поведение приложения, которое необходимо было определить и протестировать.

person SaxonMatt    schedule 25.05.2012

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

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

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

В моем случае, если я начинаю с пользовательской истории и пишу сценарии, меня интересует в основном поведение, которое проходит через API моего приложения, уровень сервиса, сущности домена, помощник и т. Д. В основном меня не так сильно интересует в том, что произойдет в пользовательском интерфейсе или в базе данных. Настоящее мясо - это весь код, написанный на стороне сервера. Это поведение меня интересует. Если вы так думаете, имеет смысл избавиться от пользовательского интерфейса и БД, потому что мы не заботимся об этих парнях. Ожидаемое поведение пользовательского интерфейса - отображение данных, которые предоставляет мое приложение. Пользовательский интерфейс - тупая штука. Ожидаемое поведение БД - хранить и извлекать сущности, которые дает или хочет мое приложение. Это тоже действительно глупая вещь. Теперь обо всем остальном, вот где вся смекалка и за что я отвечаю.

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

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

Для БД я бы написал интеграционные тесты, чтобы проверить, могут ли мои настоящие репозитории читать и записывать данные в БД.

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

person foobarcode    schedule 05.10.2012

Что высмеивать, зависит от архитектуры. Для MVVM вы можете смоделировать модель, чтобы протестировать модель представления. Для MVP вы можете смоделировать представление и / или модель, чтобы протестировать ведущего. Если вы хотите писать сквозные тесты вместо модульных, тогда вы тестируете через модель представления / презентатора на другом конце приложения (уровень сервиса / базы данных).

person Garrett Hall    schedule 25.05.2012