Как реализовать BDD на очень сложных бизнес-правилах?

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

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

  1. Войдите в базу данных «Служба запускается…»

  2. Получить данные из БД, которые необходимо отправить в другой веб-сервис

  3. Если нет данных для публикации журнала в базе данных «Нет данных для обработки…» и выйдите из службы.

  4. Если данные содержат повторяющиеся значения. Записать в базу данных «Обнаружены повторяющиеся данные, эта запись будет пропущена».

  5. Обновите статус записи, для которой были обнаружены повторяющиеся данные, например, 302

  6. Если данные равны нулю, войдите в базу данных «Запись содержит нулевое значение и не может быть обработана».

  7. Обновите статус записи соответствующим образом, например. 310

  8. Если база данных недоступна или не работает по какой-либо причине, войдите в файл «База данных не работает…»

  9. Если служба не работает, мы должны разместить журнал данных в базе данных «Служба приемника не работает».

  10. Войдите в базу данных «Выход из службы…»

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

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

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

При выполнении службы Windows с повторяющимися данными

  • Он должен войти в базу данных «Обнаружены повторяющиеся данные, эта запись будет пропущена».
  • Он должен обновить статус записи до 302

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

Во-вторых, поскольку служба взаимодействует с БД, а также с веб-службой, как я могу протестировать HttpRequest и HttpResponse, которые отправляются и принимаются службой?

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


unit-testing moq web-services bdd mspec
person Afraz Ali    schedule 03.12.2013    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Несколько простых мыслей, которые помогут держать это в перспективе:

  1. Вы говорите обучение ...
    Помните об этом и не зацикливайтесь на том, что идеально, правильно или правильно. Вы учитесь, не стесняетесь ошибаться и знаете, что со временем вы будете совершенствоваться. Продолжайте, продолжайте практиковаться, и вам станет лучше, и чем больше вы будете делать и чем больше думать об этом, тем естественнее будет чувствовать себя.
  2. BDD проверяет поведение.
    Вы используете это, чтобы сказать, что система должна вести себя определенным образом, и это подразумевает, что это должна быть система. Иногда вы все еще можете использовать пару фиктивных служб (например, службу обработки поддельных кредитных карт), но по большей части вы хотите, чтобы это доказало, что система работает должным образом. Думайте о них как об интеграционных тестах.
  3. Ваши тесты BDD должны управлять вашими модульными тестами.
    Напишите тест BDD на сбой, а затем позвольте ему определять, какие модульные тесты должны быть написаны, чтобы ваша система работала так, как вы ожидаете. По сути, это означает, что каждый ваш тест BDD также будет включать в себя набор модульных тестов.
  4. Таким образом, позвольте BDD управлять TDD, и вы получите правильный баланс тестов. Отправной точкой является ваш первый тест BDD.

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

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

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

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

person Damon    schedule 03.12.2013
comment
Большое спасибо за ваш ценный ответ. Это избавило меня от множества заблуждений. Прежде чем я подробно расскажу о моем текущем сценарии, я хотел бы задать вам пример сценария, который я написал. При выполнении службы Windows с дублирующимися данными. Он должен записывать в базу данных «Обнаружены повторяющиеся данные, эта запись будет пропущена». Он должен обновить статус записи до 302. Этот сценарий кажется вам допустимым с точки зрения BDD, поскольку он не описывает полное поведение службы, а только один сценарий ... - person Afraz Ali; 04.12.2013
comment
@AfrazAli, я не совсем уверен в этом. Мне кажется правильным, что когда вы попытаетесь скопировать запись, вы предупредите пользователя. Также кажется правильным обновить запись, чтобы указать, что пользователь пытался вставить повторяющуюся запись. Но тот факт, что вы записываете эту попытку как 302, кажется слишком низкоуровневым, по крайней мере, в отношении теста BDD. Подобно программированию интерфейса, вам нужно предоставить какой-либо метод, который заботится об этой логике, но скрывает эти детали от API (и, следовательно, от теста BDD). Он должен иметь возможность вызывать что-то вроде wasDupeAttempted() - person Damon; 04.12.2013
comment
Если пойти немного дальше, я думаю, что ваш тест BDD действительно не должен заботиться о том, что записано в базу данных, а только о том, что ваше приложение ведет себя так, как ожидалось. Информация, записанная в базу данных, вероятно, является слишком низкоуровневой, чтобы BDD мог о ней заботиться, но BDD должен иметь возможность проверять вещи на этом объекте, например, если он был сохранен, и в результате сохранения была обнаружена дублированная запись, и это он правильно показывает, что была предпринята попытка дублирования входа, чтобы вы могли на нее отреагировать. Однако его не должно волновать, что на самом деле записано в базу данных. - person Damon; 04.12.2013
comment
хорошо, спасибо, Дэймон. Не могли бы вы дать мне представление о том, как бы вы тестировали классы HttpWebRequest или HttpWebResponse, которые я использую для отправки и получения json-запросов? Или мне стоит задать для этого отдельный вопрос? - person Afraz Ali; 04.12.2013
comment
Помечено как ответ, поскольку он действительно показал мне, что делать. Теперь мне нужно работать над тем, как сделать деталь :) - person Afraz Ali; 05.12.2013
comment
Круто, HttpWeb Request and Responses, наверное, должен быть отдельным вопросом. Это отчасти сводится к вашему дизайну, но вы в основном хотите сказать, что при возникновении этого условия вы должны получить соответствующий ответ. Попробуйте запрограммировать / тестировать коды ошибок, а не строковое сообщение, если это возможно, потому что вы можете захотеть изменить свое сообщение или локализовать его в будущем; тестирование со строками довольно хрупко, потому что они могут измениться. - person Damon; 05.12.2013