BDD и функциональные тесты

Question

Я начинаю покупать в BDD. В основном, насколько я понимаю, вы пишете сценарий, который хорошо описывает критерии приемлемости для определенной истории. Вы начинаете с простых тестов, извне, используя mocks вместо классов, которые вы еще не внедрили. По мере продвижения вы должны заменять макеты реальными классами. С Введение в BDD :

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

Мой вопрос: когда вы закончите реализацию сценария, все ли используемые вами классы должны быть реальными, как в интеграционных тестах? Например, если вы используете БД, должен ли ваш код записывать данные в реальную (но легкую в памяти) БД? В конце концов, должны ли вы иметь какие-то шутки в ваших комплексных тестах?

Answer 1

Ну, это зависит :-) Как я понимаю, тесты, производимые BDD, все еще являются модульными тестами, поэтому вы должны использовать mocks для устранения зависимости от внешних факторов, таких как DB.

В полноценных тестах интеграции / функциональности, однако, вы должны явно тестировать всю производственную систему, без всяких насмешек.

Answer 2

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

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

Мы по-прежнему держим насмешки в юнит-тестах.

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

Что касается того, что вы «должны» сделать, то написание правильного кода гораздо сложнее, чем написание правильного кода. Я беспокоюсь об использовании моих сценариев, чтобы получить обратную связь от заинтересованных сторон и пользователей, прежде чем беспокоиться о том, насколько близка моя среда к производственной среде. Конечно, когда вы переходите к тому моменту, когда изменения внедряются каждые две недели, вам, вероятно, потребуется больше уверенности в том, что вы не вносите никаких ошибок.

Удачи!

Answer 3

Интеграционные тесты могут содержать заглушки / макеты для фальсификации кода / компонентов вне интегрируемых модулей.

Тем не менее, ИМХО сквозной тест должен означать не тупики / издевательства по пути, а только рабочий код. Или, другими словами, - если имитация присутствует - это на самом деле не сквозной тест.

Answer 4

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

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

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

Answer 5

Я согласен с Питером и Раткоком.Я думаю, что вы держите макеты навсегда, поэтому у вас всегда есть юнит-тесты.

Отдельно уместно дополнительно иметь интеграционные тесты (без макетов, использовать БД и т. Д.).

Иногда вы можете даже найти промежуточные элементы полезными (имитировать один фрагмент зависимого кода (DOC), но не другой).