BDD и функциональные испытания
Я начинаю вложиться в BDD. В основном, насколько я понимаю, Вы пишете сценарий, который описывает хорошо критерии допустимости для определенной истории. Вы запускаете простыми тестами, с внешней стороны - в, с помощью насмешек вместо классов, которые Вы не реализуете пока еще. В то время как Вы прогрессируете, необходимо заменить насмешки реальными классами. От Введения до BDD:
Сначала, фрагменты реализованы с помощью насмешек для установки учетной записи, чтобы быть в кредите или карте, чтобы быть допустимыми. Они формируют начальные точки для реализации поведения. Поскольку Вы реализовываете приложение, givens и результаты изменяются для использования фактических классов, которые Вы реализовали, так, чтобы к тому времени, когда сценарий был завершен, они стали надлежащими сквозными функциональными испытаниями.
Мой вопрос: Когда Вы закончите реализовывать сценарий, должны все классы Вы использовать быть реальными, как в интеграционных тестах? Например, при использовании DB код должен записать в реальное (но легкий вес, в оперативной памяти) DB? В конце у Вас должны быть какие-либо насмешки в Ваших сквозных тестах?
5 ответов
Ну, это зависит от ситуации :-) Как я понимаю, тесты, созданные с помощью BDD, все еще являются юнит-тестами, поэтому вам следует использовать моки, чтобы устранить зависимость от внешних факторов, таких как БД.
В полноценных интеграционных / функциональных тестах, однако, вы, очевидно, должны тестировать против всей производственной системы, без каких-либо макетов.
Интеграционные тесты могут содержать заглушки/моки, чтобы сымитировать код/компоненты вне модулей, которые вы интегрируете.
Однако, IMHO, сквозное тестирование должно означать отсутствие заглушек/моков на пути, а только производственный код. Или другими словами - если mocks присутствуют - это не совсем сквозной тест.
Да, к моменту запуска сценария в идеале все ваши классы будут реальны. Сценарий демонстрирует поведение с точки зрения пользователя, поэтому система должна быть такой, какой ее видит пользователь.
На заре BDD мы обычно начинали с имитаций в сценариях. Я больше этим не заморачиваюсь, потому что продолжать издеваться над уровнями - это большая работа. Вместо этого я иногда буду делать такие вещи, как жестко запрограммированные данные или поведение, если это позволяет мне быстрее получать обратную связь от заинтересованных сторон.
Тем не менее, мы по-прежнему сохраняем имитации в модульных тестах.
Для таких вещей, как базы данных, конечно, вы можете использовать БД в памяти или что-то еще, что поможет вам быстрее получить обратную связь. В какой-то момент вам, вероятно, следует запустить свои сценарии в системе, максимально приближенной к производственной. Если это слишком медленно, вы можете сделать это за ночь, а не как часть обычного цикла сборки.
Что касается того, что вы «должны» делать, написать правильный код намного сложнее, чем написать правильный код. Я беспокоюсь об использовании своих сценариев для получения обратной связи от заинтересованных сторон и пользователей, прежде чем беспокоиться о том, насколько моя среда близка к производственной. Когда вы дойдете до того момента, когда изменения развертываются каждые пару недель, вы, вероятно, захотите больше уверенности в том, что вы не вносите никаких ошибок.
Удачи!
Я согласен с Питером и Раткоком. Я думаю, что вы сохраняете моки навсегда, чтобы у вас всегда были юнит-тесты.
Отдельно стоит добавить интеграционные тесты (без макетов, с использованием БД и т.д. и т.п.).
Вы даже можете найти промежуточные тесты полезными в некоторых случаях (высмеивать одну часть зависимого кода (DOC), но не другую).
Я только недавно изучал BDD и, в частности, jBehave. Я работаю на довольно крупных предприятиях с большим количеством водопадов, людьми ориентированными на церемонию.Я рассматриваю BDD как способ взять бизнес-варианты использования и превратить их непосредственно в тесты, которые разработчик затем может превратить либо в модульные, либо в интеграционные тесты.
BDD кажется мне не только способом помочь разработчикам понять, чего хочет бизнес, но также и способом гарантировать, что эти требования будут точно представлены в максимально возможной степени.
Я считаю, что если вы имеете дело с mocks, вы выполняете модульные тесты. Вам нужно как модульное тестирование, чтобы проверить детали работы классов, так и интеграции, чтобы проверить, хорошо ли класс взаимодействует с другими. Я считаю, что разработчики часто связаны между собой, но лучше быть как можно более ясным и держать их отдельно друг от друга.