База джуна: REST, юнит-тесты, терминал и отладка

Есть навыки, которые не привязаны ни к языку, ни к фреймворку. Сменишь React на Vue, Node на Go, а они останутся: понять чужой API, написать тест, не потеряться в терминале, найти баг быстрее чем за день. Этот урок собирает четыре таких навыка в один базовый набор. Каждый из них дальше раскрывается в своём разделе курса, здесь смотрим на всю поляну сразу.

REST концептуально

Когда два сервиса разговаривают по HTTP, есть два способа думать об этом разговоре. RPC мыслит глаголами: «вызови функцию createUser». REST мыслит существительными: «вот ресурс /users, сделай ему POST».

Разница не косметическая. В REST у тебя ограниченный набор глаголов (GET, POST, PUT, PATCH, DELETE) и бесконечный набор существительных. Это даёт предсказуемость: увидев DELETE /orders/42, ты знаешь, что произойдёт, не открывая документацию. В RPC каждый метод уникален, и без документации ты слеп.

RPC-стиль:   POST /api/createOrder
             POST /api/cancelOrder
             POST /api/getOrderById

REST-стиль:  POST   /orders        создать
             DELETE /orders/42     отменить
             GET    /orders/42     прочитать

На практике почти никто не делает «чистый» REST по диссертации Филдинга, и это нормально. Важно понимать спектр: от «HTTP как транспорт для вызовов» до «ресурсы, методы, коды ответов, ссылки». Подробный разбор проектирования с пагинацией, версионированием и кодами ошибок ждёт тебя в уроке REST: проектирование API.

Юнит-тесты: AAA и пирамида

Цель тестирования не «покрытие 80 процентов», а уверенность: можно менять код и быстро узнавать, что ничего не сломалось. Юнит-тест это самый дешёвый способ такую уверенность получить.

Скелет любого юнит-теста описывается тремя буквами AAA:

test('скидка 10 процентов для заказа от 1000', () => {
  // Arrange: подготовка
  const order = makeOrder({ total: 1500 });

  // Act: одно действие
  const discounted = applyDiscount(order);

  // Assert: проверка результата
  expect(discounted.total).toBe(1350);
});

Подготовка данных это половина искусства. Фабрики вроде makeOrder прячут нерелевантные детали и оставляют на виду только то, что важно для конкретного теста. Если в тесте двадцать строк настройки и одна проверка, тест врёт о том, что он проверяет.

Code coverage полезен как термометр, но не как цель. Сто процентов покрытия с проверками expect(result).toBeDefined() хуже, чем семьдесят с осмысленными ассертами.

Пирамида тестирования отвечает на вопрос «сколько каких тестов писать»: много быстрых юнитов в основании, меньше интеграционных в середине, несколько E2E на вершине. Почему именно так и когда пирамида превращается в «трофей», разобрано в уроке Пирамида, трофей и сдвиг эпохи ИИ, а полная анатомия юнит-теста в Анатомия юнит-теста.