Характеризующие тесты

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

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

Характеризующий тест утверждает фактический вывод кода, а не правильный. Это тот ход, что разрывает курицу-и-яйцо. Чтобы написать тест, не нужно знать правильный ответ; нужен текущий ответ, и код сам тебе его сообщит. Приём Физерса: вызови функцию, посмотри, что она возвращает, и впиши ровно это значение в утверждение — даже если оно выглядит неверным.

// Ты подозреваешь, что правильный ответ ~7.50, но ты не утверждаешь этого.
// Ты запускаешь код и утверждаешь то, что он реально выдал.
test('characterizes shippingCost for a 2kg domestic parcel', () => {
  expect(shippingCost({ weightKg: 2, zone: 'domestic' })).toBe(6.99);
});

Откуда взялось 6.99? Ты написал .toBe(0), запустил, сообщение об ошибке сказало Expected 0, Received 6.99, и ты вставил 6.99 обратно. Тест теперь проходит и фиксирует эту пару вход-выход. Ты не утверждаешь, что 6.99 верно. Ты утверждаешь «вот что система делает сегодня», и теперь любой рефакторинг, который это изменит, упадёт громко.

Фиксируй поведение, которое реально прогоняет код, включая уродливые ветки — покрытие путей важнее покрытия «счастливых» случаев. Сеть с дырами даёт поведению проскользнуть. Ветки, которые скорее всего сломаются при рефакторинге, — это странные: нулевой вес, фолбэк на неизвестную зону, причуда округления, ранний return, о котором никто не помнит. Характеризуй их осознанно. Быстрый способ их найти — скормить разнообразные входы и снять снапшот выводов массово — подход «золотого эталона» — так ты фиксируешь широкую полосу поведения дёшево, а не пишешь по одному утверждению вручную.

// Золотой эталон: фиксируем много пар вход/выход разом.
const cases = [
  { weightKg: 0,   zone: 'domestic' },
  { weightKg: 2,   zone: 'domestic' },
  { weightKg: 2,   zone: 'intl' },
  { weightKg: 99,  zone: 'unknown' }, // путь фолбэка
];
test('golden master: shippingCost across known paths', () => {
  const observed = cases.map((c) => ({ ...c, cost: shippingCost(c) }));
  expect(observed).toMatchSnapshot(); // первый прогон записывает, последующие сравнивают
});

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

Фиксация текущего поведения фиксирует и баги — и это нормально, пока ты держишь «зафиксировать» и «исправить» двумя раздельными, раздельно тестируемыми решениями. Это senior-режим отказа. Ты характеризуешь функцию, снапшот включает строку, говорящую, что международная доставка для 0кг возвращает 4.20, когда очевидно должно быть 0, и теперь твой зелёный набор закрепляет этот баг. Если ты относишься к характеризующему тесту как к спецификации, ты будешь бояться когда-либо его исправить, потому что исправление делает набор красным, а «тесты же проходили».

Дисциплина: характеризующий тест — это временное описание реальности, а не требование. Рефакторь под ним — зелёный значит «я сохранил поведение, включая ошибочные части, улучшая структуру». Затем, как отдельный коммит с собственным намерением, измени ошибочное поведение: напиши новый тест, утверждающий правильный 0, посмотри, как старая характеризующая строка падает, обнови её намеренно и отметь в коммите, что это осознанное изменение поведения, а не регрессия. Рефакторинг держит сеть зелёной; исправление делает её красной нарочно. Смешение этих двух — то, как команды каменеют от страха перед собственным легаси.