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

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

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

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

Это продолжение истории, которая началась здесь, а продолжалась здесь и здесь.

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

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

Что показали испытания? Команда работает, но… в том сценарии использования, в котором ее приходится задействовать, ее неудобно настраивать.

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

it('execute should return promise', () => {

  request.configure(options);

  request.execute().then((result) => {

    expect(result.Id).toEqual(1);
    expect(result.Name).toEqual('Jack');
  });
});

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

Начальная стадия обработки содержит десяток идентичных операций с отправкой запросов на извлечение данных некоего конкретного пользователя из различных таблиц базы. Есть предположение что при этом достаточно большую часть кода можно будет использовать повторно в виде абстракции Request. Попробую предположить как этим можно было бы пользоваться. Напишу первый тест: