Я пытаюсь понять всю методологию TDD, и поэтому я не знаю, как представить это как хороший лаконичный вопрос, так что вот длинная вытянутая версия.
Кажется, я испытываю разрыв между боулингом (Martin), деньгами (Feathers) и другими подобными играми / простыми примерами и полностью работающим приложением Enterprise.
Я пытаюсь выяснить, упускаю ли я что-то вроде концепции функции, которая, насколько я понимаю, является чем-то, что повышает ценность для бизнеса или как правильно разделять проблемы при выполнении TDD, и как каждый из них затем применим к другому.
Если это определение функции является жестким правилом, то такие вещи, как ведение журнала и отчеты об ошибках, не являются функциями. Означает ли это, что TDD не предоставляет средства для регистрации и уведомления?
Не пытаясь начать какие-либо войны, я почти уверен, что это не так, поэтому я тогда говорю себе, что «ценность для бизнеса» должна переключать промежуточное приложение с бизнес-ценности клиентов на бизнес (создатель приложения) значение.
Так что я тогда пытаюсь включить его, как этот общий пример
От:
Как математик идиот
Когда я ввожу 2, нажмите добавить, введите 2, затем нажмите =
Я хочу 4 вернулся.
Для того, чтобы:
Как системный аналитик, контролирующий систему
Когда пользователь входит в функцию, которая приводит к необработанной ошибке
Я хочу, чтобы текущее состояние приложения, сгенерированное исключение и трассировка стека были внесены в журнал и отправлено электронное письмо в список рассылки системного аналитика.
А затем:
Как бизнес-аналитик, обеспечивающий обработку всех заказов клиентов
Когда пользователь отправляет электронный заказ, а информация о маршрутизации или учете не проверяется
Я хочу, чтобы неверные данные учета и маршрутизации были введены в журнал и отправлены по электронной почте вместе с файлом заказа, прикрепленным к группе пользователей бизнес-аналитика.
если проблема не в том, что не удалось связаться с базой данных для поиска информации о клиенте из-за проблем с сетью, введите в журнал «базу данных не удалось найти информацию о клиенте из-за проблем с сетью» в журнал и отправьте электронное письмо с сообщением об ошибке на список рассылки системного аналитика.
Тогда это начинает расширяться в нечто, что, я думаю, было бы совершенно неприемлемо:
Как электронная проверка выполнения заказа
Когда заказ получен
Я хочу проверить, что файл x12 переведен в обычный файл, и если он не проходит проверку или журнал перевода, отправьте сообщение об ошибке по электронной почте.
информация о заказе и статус извлекаются и загружаются в базу данных
плоский файл отправляется в очередь на as400, а статус обновляется в базе данных
as400 отправляет подтверждение, что они получили заказ, и статус обновляется в базе данных
as400 отправляет подтверждение плоского файла и статус обновляется в базе данных
подтверждение транслируется в x12, а статус обновляется в базе данных
подтверждение x12 направляется соответствующим образом, и статус обновляется в базе данных
подтверждение отправляется клиенту, а статус обновляется в базе данных
если x12 содержит недопустимые данные, зарегистрируйте ошибку, отправьте электронное письмо и
если плоский файл не извлечен из очереди в течение 2 минут, зарегистрируйте ошибку, отправьте электронное письмо
и т. д. до степени x возможных сценариев ошибок.
Даже если вы разбили каждый элемент на отдельную «особенность», у вас все еще есть проблемы с ведением журнала, уведомлением системного аналитика о том, что приложение сгенерировало исключение, произошла сетевая ошибка, не найдена база данных и т. Д., Или бизнес-группе, которая получила заказ с нераспознанным номер счета был встречен и т. д.
Добавление любого из них в класс в качестве метода, атрибута и т. Д., По-видимому, нарушает принцип единой ответственности.
Примерно в это же время все начинает вращаться, у меня кружится голова, появляется одышка и учащенное сердцебиение
Итак, поскольку меня так смущает, что я не могу понять, как это сформулировать как сформулированный вопрос, я постараюсь подытожить его следующим образом.
Как вы определяете, когда / где и как разбить эти вещи и разделить их?
Легко сказать, разбить их на наименьший кусок, который предлагает ценность для бизнеса, но когда вы не можете иметь один кусок без множества других частей, каков «реальный» ответ? Все это не вписывается в одну наклейку.
Я открыт для ответов, которые включают больше книг, учебных пособий, видео, но я думаю, если бы были какие-то приложения реального мира, которые учитывают эти типы вещей, которые придерживаются принципов гибкой и 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
Повторите это снова, заменив сводку на порядок. Вот что я придумал.