Перейти к содержимому
Прогресс курса
0 из 8 модулей

Модуль 5

Рабочие сценарии по ролям

Разработчик проводит скидку по red-green, тестировщик строит тест-план и регресс-тесты для POST /api/orders, аналитик переписывает README по коду и оценивает удаление legacy-эндпоинта.

25 мин

Чему научишься

  • провести фичу скидки по red-green: падающий тест до реализации
  • собрать с агентом тест-план эндпоинта и превратить его в тесты
  • обновить README по фактическому коду и оценить влияние удаления эндпоинта

Модуль собирает весь курс в три рабочих сценария. Разработчик проводит скидку по red-green, тестировщик строит тест-план и регресс-тесты для POST /api/orders, аналитик переписывает README и оценивает удаление legacy-эндпоинта. Сценарии идут подряд, и каждый проходят все: навык red-green пригодится тестировщику, оценка влияния пригодится каждому, кто трогает общий API.

Состояние orders-api к этому моменту: баг отрицательного quantity исправлен в модуле 2, в src/services/pricing.ts висит TODO про скидку 10% при заказе от 1000 ₽, у маршрута orders нет ни одного теста, README не знает про /api/menu и /api/stats. Если что-то из этого пропущено, сценарий всё равно сработает: агент найдёт расхождение и покажет его.

Сценарий 1. Разработчик: скидка по red-green

Требование лежит в src/services/pricing.ts комментарием TODO: скидка 10% при заказе от 1000 ₽. Эталон для проверки считается из меню: cap × 3 + chz × 2 = 300 × 3 + 420 × 2 = 1740 ₽, со скидкой 1566 ₽. Это число фиксируй в тесте до любой правки кода.

Red-green — это порядок работ. Red: тест с ожиданием 1566 падает, потому что скидки ещё нет. Green: реализация в orderTotal, от которой тест проходит. Промпты раздели по агентам: plan составляет тест-план, ты проверяешь числа, build добавляет тест и реализацию. План до кода дешевле ревью после.

Шаг 1. Тест-план в plan-агенте

TODO в src/services/pricing.ts: скидка 10% при заказе от 1000 ₽. Сделаем red-green. Составь план: сначала тест с ожиданием 1566 для заказа cap × 3 + chz × 2, потом реализация. Код не пиши.

Читаю src/services/pricing.ts и tests/pricing.test.ts. План: 1) новый файл tests/pricing-discount.test.ts на node:test: orderTotal для cap × 3 и chz × 2 должен вернуть 1566, сейчас вернёт 1740, тест упадёт — это red; 2) в orderTotal после свёртки суммы вернуть 0.9 суммы при значении от 1000; 3) существующий тест на 890 ₽ без скидки остаётся зелёным, финальный прогон npm test. Кода не писал. Переключайся на build и передавай план одним сообщением.

tests/pricing-discount.test.ts
import { test } from "node:test";
import assert from "node:assert/strict";
import { orderTotal } from "../src/services/pricing";

test("orderTotal даёт скидку 10% при сумме от 1000 ₽", () => {
  // cap × 3 + chz × 2 = 1740, со скидкой 10% — 1566
  assert.equal(
    orderTotal([
      { menuId: "cap", quantity: 3 },
      { menuId: "chz", quantity: 2 },
    ]),
    1566,
  );
});
Падающий тест до реализации: orderTotal вернёт 1740, а не 1566

Переключись на build через Shift+Tab и передай план одним сообщением: добавить тест, показать падение, реализовать скидку, прогнать npm test. Агент сначала запустит тесты и покажет красный прогон, затем предложит дифф src/services/pricing.ts. Дифф читай до apply: в нём должны быть две строки про скидку и ноль правок в остальном файле.

Шаг 2. Реализация в build-агенте

Реализуй план по red-green: создай tests/pricing-discount.test.ts, прогони npm test и покажи падение, затем сделай скидку в src/services/pricing.ts и добейся зелёного прогона.

создан файл tests/pricing-discount.test.ts

npm test: 3 теста, 1 упал — ожидалось 1566, получено 1740

Red подтверждён: тест падает ровно на скидке, остальные два зелёные. Правка в orderTotal: при сумме от 1000 ₽ возвращаю сумму минус 10%. Показываю дифф перед записью.

изменён файл src/services/pricing.ts

npm test: 3 теста, 3 прошли

Готово. Дифф в src/services/pricing.ts занял две строки, тест на 890 ₽ без скидки не задет. До реализации прогон был красным, значит тест действительно цепляет скидку.

Сценарий 2. Тестировщик: тест-план и регресс-тесты

У src/routes/orders.ts нет ни одного теста, в tests/ лежит только pricing.test.ts. Именно поэтому баг с отрицательным quantity из модуля 2 дожил до курса незаметно: нечему было упасть. Задача тестировщика закрыть маршрут тест-планом и тестами на POST /api/orders и PATCH /api/orders/:id/status.

Работай двумя промптами. Первый просит план без кода, ты читаешь и дополняешь. Второй просит тесты по плану. Сервер для HTTP-тестов подними в соседней вкладке Windows Terminal командой npm run dev, он слушает порт 3000.

Промпт 1. Только план

Собери тест-план для POST /api/orders и PATCH /api/orders/:id/status. Позитивные и негативные кейсы: quantity меньше 1, несуществующий menuId, пустой items, невалидный status. Отдельно регресс-кейс на баг модуля 2: quantity −2 должен давать 400. Только план, код тестов не пиши.

Читаю src/routes/orders.ts, src/services/pricing.ts и data/db.json. План. Позитивные: P1 валидный заказ из двух позиций — 201 и total по ценам меню; P2 смена статуса new → confirmed → done — 200 с обновлённым заказом. Негативные: N1 quantity −2 — 400, регресс на фикс из модуля 2; N2 quantity 0 — 400; N3 несуществующий menuId — 400; N4 пустой items — 400; N5 без customer — 400; N6 несуществующий id заказа — 404; N7 status cancelled — 400. Вопрос по N3: в маршруте нет проверки menuId, исключение из orderTotal уйдёт наружу, поэтому предлагаю в плане ожидание 400 с пометкой проверить фактический код ответа. Жду твоих правок плана.

Дополни план своими кейсами и дай второй промпт: тесты по плану, файл tests/orders.test.ts, прогон npm test. Расхождения с планом агент должен показать отдельно: так тестировщик получает список новых дефектов вместе с зелёными тестами, а тесты на undiscovered поведение не пишутся вслепую.

Промпт 2. Тесты по плану

Пиши тесты по плану в tests/orders.test.ts, сервер поднят на localhost:3000. Прогони npm test и покажи результат по каждому кейсу.

создан файл tests/orders.test.ts: 9 кейсов из плана

npm test: 12 тестов, 1 упал — N3 ждал 400, пришёл 500

Кейс N3 вскрыл дефект: несуществующий menuId в POST /api/orders даёт 500, план ждал 400. orderTotal бросает исключение, маршрут его не перехватывает — это замечание 2 из ревью модуля 4. Тест N3 временно фиксирует фактический ответ 500 с комментарием и пометкой «дефект: нет валидации menuId», чтобы прогон оставался зелёным.

npm test: 12 тестов, 12 прошли

Итог по сценарию: 11 кейсов держат контракт маршрута, регресс N1 (quantity −2 → 400) защищает фикс из модуля 2, N3 документирует дефект с комментарием. Для N3 заводи задачу на валидацию menuId.

Сценарий 3. Аналитик: документация и оценка влияния

README.md в orders-api устарел: он не знает про /api/menu и /api/stats, обещает Node 18 и npm start, хотя в package.json живут npm run dev, npm test и npm run typecheck. Паттерн аналитика — документация из кода. Агент читает src/routes/*.ts и package.json, каждое утверждение README сверяется с фактическим поведением, устаревшее выпадает.

Свежий README по коду

Перепиши README.md по фактическому коду: назначение, запуск и тесты из package.json, эндпоинты из src/routes. Сначала покажи структуру, потом записывай.

Структура: назначение (REST-сервис заказов кофейни, Express + TypeScript, база data/db.json без отдельной СУБД); запуск (npm install, npm run dev, порт 3000); проверка (npm test, npm run typecheck); API — 9 маршрутов: /health, меню (GET /api/menu?category=, GET /api/menu/:id), заказы (GET /api/orders?status=, GET /api/orders/:id, POST /api/orders, PATCH /api/orders/:id/status со статусами new|confirmed|done), сводка GET /api/stats с полями orders, byStatus, revenue и legacy GET /api/v1/report в text/plain. Пишу файл.

обновлён README.md

Готово. Каждая строка сверена с кодом: скрипты из package.json, поля ответа /api/stats из src/routes/stats.ts, список статусов из src/routes/orders.ts.

Вторая задача аналитика — оценка влияния. Вопрос заказчика: можно ли удалить GET /api/v1/report. Агент отвечает по трём пунктам: кто использует эндпоинт, покрывает ли замена потребность, что входит в чек-лист миграции. Вывод по коду и комментариям репозитория агент делает сам; внешних потребителей он не видит, поэтому живой трафик проверяют до удаления.

Оценка удаления /api/v1/report

Оцени влияние удаления GET /api/v1/report: кто его использует, что должно остаться в /api/stats, и какой нужен чек-лист миграции.

Читаю src/routes/legacy.ts и src/index.ts. Кто использует: комментарий в коде говорит, что кассы перешли на /api/stats, эндпоинт оставили на всякий случай; других вызовов в репозитории нет, кроме регистрации маршрута. Замена: кассам нужна сводка — количество заказов, разбивка по статусам, выручка — всё это /api/stats уже отдаёт. Вывод: удалять безопасно. Чек-лист миграции: 1) предупредить владельцев кассовых интеграций, 2) неделю смотреть обращения к /api/v1/report в логах шлюза, 3) сверить поля /api/stats с потребностью касс, 4) удалить src/routes/legacy.ts и строку app.use в src/index.ts, 5) вычеркнуть эндпоинт из README и упомянуть удаление в истории изменений.

Чек-лист. Разработчик

  1. TODO в src/services/pricing.ts: скидка 10% при заказе от 1000 ₽. Составь план red-green: сначала тест с ожиданием 1566 для cap × 3 + chz × 2, потом реализация. Код не пиши.
  3. Реализуй план по red-green: создай tests/pricing-discount.test.ts, прогони npm test и покажи падение, затем сделай скидку в src/services/pricing.ts и добейся зелёного прогона.
  4. npm test

Отмечено 0 из 4

Чек-лист. Тестировщик

  1. npm run dev
  2. Собери тест-план для POST /api/orders и PATCH /api/orders/:id/status. Позитивные и негативные кейсы: quantity меньше 1, несуществующий menuId, пустой items, невалидный status. Только план, код не пиши.
  4. Пиши тесты по плану в tests/orders.test.ts, сервер на localhost:3000. Прогони npm test и покажи результат по каждому кейсу.

Отмечено 0 из 4

Чек-лист. Аналитик

  1. Перепиши README.md по фактическому коду: назначение, запуск и тесты из package.json, эндпоинты из src/routes. Сначала покажи структуру, потом записывай.
  2. Оцени влияние удаления GET /api/v1/report: кто использует, что должно остаться в /api/stats, чек-лист миграции.

Отмечено 0 из 3

Проверь себя

Вопрос 1 из 5

Что такое red-green в сценарии разработчика?

Шпаргалка модуля

Паттерны промптов

Red-green фича
plan пишет тест-план с эталонным числом (1740 → 1566), build добавляет падающий тест и только потом реализацию
Тест-план без кода
два промпта: сначала «выдай тест-план, код не пиши», после твоих правок «напиши тесты по плану»
Документация из кода
агент читает src/routes и package.json и пишет README по фактическому поведению
Оценка влияния
кто использует, покрывает ли замена, чек-лист миграции; решение принимает человек

Команды сценариев

npm run dev
поднять orders-api на порту 3000 в соседней вкладке терминала
npm test
прогон тестов node:test из папки tests/
Shift+Tab
переключение plan ↔ build между шагами сценария

Ссылки модуля