Первые тесты

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

У тестов две роли. Первая — страховка: меняете код сколько угодно, запускаете тесты и сразу видите, что уцелело, а что нет. Вторая — спецификация: набор тестов читается как список обещаний «эта функция ведёт себя вот так». Тест описывает поведение честнее комментария: устаревший комментарий молчит, а устаревший тест проваливается.

Любой тест — от однострочника до промышленного — устроен одинаково. Есть ожидание: значение, которое должно получиться. Есть факт: то, что код вернул на самом деле. Осталось их сравнить.

let expected = 4;
let actual = 2 + 2;
console.log(actual === expected);

Не хватает одного: чтобы провал нельзя было проглядеть в потоке вывода. Для этого есть инструмент получше голого console.log.

Метод console.assert(условие, сообщение) работает как строгий, но немногословный проверяющий. Условие истинно — он молчит. Условие ложно — печатает в консоль ошибку с вашим сообщением.

console.assert(2 + 2 === 4, "этого сообщения никто не увидит");
console.assert(2 + 2 === 5, "два плюс два — не пять!");
console.log("скрипт дошёл до конца");

Обратите внимание на две вещи. Успешные проверки не засоряют консоль — видны только провалы. И проваленный assert не останавливает скрипт: выполнятся и все остальные проверки, так что за один запуск вы получаете полную картину.

Напишем функцию pow(x, n), возводящую x в натуральную степень n, и сначала просто посмотрим на неё глазами.

function pow(x, n) {
  let result = 1;
  for (let i = 0; i < n; i++) result *= x;
  return result;
}
console.log(pow(2, 3));

Один запуск «на глаз» — хорошо, но закрепим поведение тестами: три проверки, три разных сочетания аргументов. Функция та же, просто записана в одну строку, чтобы пример был короче.

function pow(x, n) { let r = 1; for (let i = 0; i < n; i++) r *= x; return r; }
console.assert(pow(2, 3) === 8, "pow(2, 3) должно быть 8");
console.assert(pow(3, 2) === 9, "pow(3, 2) должно быть 9");
console.assert(pow(5, 1) === 5, "pow(5, 1) должно быть 5");
console.log("прогон завершён");

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

В настоящих проектах тесты пишут не на console.assert, а с помощью тест-фреймворков — самые популярные сегодня Jest и Vitest. Внутри — то же сравнение ожидания с фактом, но с удобствами: тесты живут в отдельных файлах, у каждого есть человекочитаемое название, а после запуска печатается отчёт — сколько прошло, сколько упало и где именно. Устанавливать их сейчас не нужно: главное, что идея внутри ровно та, которую вы уже освоили.

function expect(value) {
  return { toBe: (target) => console.log(value === target ? "ok" : "провал: " + value) };
}
expect(2 + 2).toBe(4);
expect(2 + 3).toBe(4);

С чего начинать проверки? Правило простое: сначала обычные случаи — типичные аргументы, ради которых функция и написана. Потом граничные — значения на краях допустимого: ноль, отрицательные числа, пустая строка. Обычные тесты ловят «функция вообще не работает», граничные — «функция работает, но не всегда».

function pow(x, n) { let r = 1; for (let i = 0; i < n; i++) r *= x; return r; }
console.assert(pow(2, 0) === 1, "нулевая степень");
console.log(pow(2, 0));
console.log(pow(2, -1));

Граница нашла баг: при отрицательной степени цикл не выполняется ни разу, и функция возвращает 1 вместо 0.5. Все три «обычных» теста из раздела про pow этого не заметили бы никогда. Дальше два честных пути: починить функцию — или договориться, что она работает только при n >= 0, и зафиксировать это отдельным тестом.

Мнемоника границ: ноль, минус, пусто