Как правильно создавать функции, тесты, истории и разбивать их

Я пытаюсь понять всю методологию TDD, и поэтому я не знаю, как представить это как хороший лаконичный вопрос, так что вот длинная версия. Кажется, я испытываю разрыв между боулингом (Martin), деньгами (Feathers) и другими подобными играми / простыми примерами и полностью функционирующим приложением Enterprise.

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

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

Затем я пытаюсь переключить его, как этот общий пример. From: Как математический идиот. Когда я ввожу 2, нажимаю add, вводю 2, затем нажимаю = Я хочу, чтобы 4 вернулось.

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

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

Затем это начинает превращаться в нечто, что, на мой взгляд, было бы совершенно неприемлемо: как электронная проверка выполнения заказа. Когда заказ получен, я хочу проверить, что файл x12 преобразуется в плоский файл, и если он не проходит проверку или журнал перевода, отправьте электронное письмо по электронной почте. Если информация и статус заказа извлечены и загружены в базу данных, плоский файл отправляется в очередь на as400, а статус обновляется в базе данных, as400 отправляет подтверждение получения заказа и статус обновляется в базе данных. as400 отправляет подтверждение плоского файла, и статус обновляется в базе данных, подтверждение переводится в x12, а статус обновляется в базу данных, подтверждение x12 направляется соответствующим образом, а статус обновляется в базе данных, и подтверждение отправляется клиенту. и статус обновляется в базе данных, если x12 содержит недопустимые данные, регистрируйте ошибку, отправьте электронное письмо, и если плоский файл не извлечен из очереди в 2 минуты зарегистрируйте ошибку, отправьте электронное письмо и т. Д. С указанием всех возможных сценариев ошибки.

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

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

Как вы определяете, когда / где и как разбить эти вещи и разделить их? Легко сказать, разбить их на наименьший кусок, который предлагает ценность для бизнеса, но когда вы не можете иметь один кусок без множества других частей, каков "реальный" ответ? Все это не вписывается в один липкий.

Я открыт для ответов, которые включают в себя больше книг, учебных пособий, видео, но я думаю, если бы были какие-то приложения реального мира, которые учитывают эти типы вещей, которые придерживаются принципов гибкой и TDD, которые, вероятно, обеспечат наибольшую ценность? По общему признанию, я относительно новичок в этом, но я просмотрел книги Martin/Feathers/Osherove, я видел несколько катов по крестикам, боулингу, простым числам и т. Д., Но нет регистрации, нет сообщений об ошибках, нет из такого рода "реального мира".

Позвольте мне попробовать что-то еще.

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

Feature: Check for the presence of a summary file
  In order to verify all orders were sent through MQ from the mainframe
  a summary file must be found to determine the expected orders.

  Scenario: A summary file has not been sent
    Given a summary file does not exist
    When I check for the existence of a file
    Then I should sleep for 5 minutes

  Scenario: A summary file has been sent
    Given a summary file does exist
    When I check for the existence of a file
    Then I should validate the summary file

Feature: Validate the summary file
  In order to process a summary file
  summary file must be valid

  Scenario: A valid summary file exists
    Given a valid summary file
    When I validate the summary file
    Then I should upload the order details to the order details DB.

  Scenario: An invalid summary file exists
    Given a invalid summary file
    When I validate the summary file
    Then I should log the errors encountered
    And email the erroneous file to the analyst email group

Повторите это снова, заменив сводку заказом. Это то, что я придумал.

Источник

3 ответа

Вы сбиваетесь с пути, думая, что:"... у вас не может быть одного куска без множества других…"

Раскалывание историй - это навык. Это требует практики, и это может быть трудно стать хорошим. Эта страница объясняет концепцию и дает ссылки на ресурсы о разделении истории.

Вот одна из ваших идей о том, что у вас возникли проблемы с расставанием:

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

Я вижу по крайней мере 4 истории в этом параграфе:

  1. Как BA, во время сбоя при вводе заказа из-за неверной учетной записи и информации о маршруте, я хочу, чтобы информация об учетной записи и маршрутизации была отправлена ​​в группу BA по электронной почте вместе с файлом заказа, чтобы кто-то знал, чтобы получить правильную информацию и повторно ввести заказ.

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

  3. Как BA, во время сбоя при вводе заказа из-за "не удается связаться с базой данных", я хочу, чтобы сообщение об ошибке "не удалось связаться с базой данных для поиска информации о клиенте из-за проблем с сетью", отправленное по электронной почте в список SA, чтобы проблемы с базой данных / сетью можно проанализировать и улучшить.

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

И если ваша команда хорошо работает с TDD, не должно быть слишком сложно реализовать каждую из этих историй отдельно. Ваш код будет защищен тестами, так что если кто-то, работающий с картой 4, нарушит функциональность карты 1, надеюсь, тест ее поймает.

Источник

Вы определенно не можете сразу перейти к своей самой продвинутой истории (перевод файла x12, yikes) - когда вы имеете дело с незрелой системой, вы должны разбить огромные сложные функции на понятные истории, которые вы можете оценить и представить в течение итерации.

Я начну с вашей второй пользовательской истории, которой, я надеюсь, будет достаточно:

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

Я бы начал с того, что разбил это далее на две пользовательские истории:

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

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

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

Скажем, вы заставили бизнес подписать историю пользователя номер два. Если вы не используете библиотеку для обработки электронной почты, вы можете немедленно начать практиковать разработку через тестирование, просто подумав, что вы хотите сделать в глобальном обработчике ошибок (который уже регистрирует необработанные исключения). Для этого необходимо:

  • Получить один или несколько адресов электронной почты для списка получателей.
  • Получите тему.
  • Получить любой дополнительный контент.
  • Отправляйте почту с помощью любого используемого вами механизма.

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

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

Источник

Я немного поработал над этим, поэтому вот несколько вещей, которые я написал, которые могут помочь:

Разбивая видение на особенности, истории, сценарии и код:

http://www.infoq.com/articles/pulling-power

Расщепление истории:

http://lizkeogh.com/2008/09/11/splitting-up-stories/

Обработка технических историй (ведение журнала и т. Д.):

http://lizkeogh.com/2008/09/10/feature-injection-and-handling-technical-stories/

Все отзывы приветствуются.

Источник
Другие вопросы по тегам