Техдолг спецификаций не исчезает после исправления. Он мигрирует.

Исправление проблемы не всегда её устраняет. Иногда вы просто переносите её в другое место.

Недавно я проводил аудит проекта на предмет техдолга спецификаций. Это пробелы в инструкциях, которые приводят к багам или некорректному поведению ИИ. Я исправил семь конкретных моментов. После исправлений тесты прошли. Всё выглядело «зелёным».

Но долг не исчез. Он мигрировал из feature-файлов в step definitions.

Вот чему я научился, исправляя эти пункты:

  • Важна точность. Вместо «ответ быстрый» говорите «ответ возвращается в течение 12 секунд после отправки заказа». Это фиксирует временные рамки.
  • Избегайте двусмысленности. «Повторено 2 раза» — это неясно. Означает ли это 2 попытки всего или 3? Используйте «не более 2 запросов на оплату в общей сложности», чтобы быть уверенным.
  • Называйте механизм. Фраза «запасы высвобождаются» слишком расплывчата. Уточните: «сервис инвентаризации получает запрос на высвобождение товара X».
  • Убирайте ложные гарантии. Если шаг проходит только потому, что фича ещё не реализована, удалите этот шаг. Проходящий тест для несуществующего процесса — это ложь.
  • Определяйте, что такое «корректно». Никогда не используйте слова вроде «корректный» или «надлежащий» без конкретных значений. Используйте «содержит order_id 123» вместо «содержит правильный id».

Я создал фреймворк для поиска таких проблем. Задавайте эти пять вопросов для каждого сценария:

  • Кто отвечает за этот сценарий?
  • Какие решения это оставляет открытыми?
  • Все ли термины здесь определены?
  • Это описание поведения или реализации?
  • Чего не хватает в этом описании?

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

Спецификация гласит: «создать заказ через API». На самом деле код просто вставляет заказ напрямую в базу данных, чтобы сэкономить время. Тест проходит, но долг переместился из требований в реализацию.

Не пытайтесь написать идеальные спецификации с первого раза. Пишите их, проводите аудит и исправляйте.

Источник: https://dev.to/diyaburman/spec-debt-doesnt-disappear-when-you-fix-it-it-migrates-d25

Дополнительное обучающее сообщество: https://t.me/GyaanSetuAi