⚠️ Draft documentation
Work in progress — some sections may be incomplete, typos possible. Last updated: 2026-05-10.
EN | DE | RU | FR | ES

Комментарий к diff: utilities/rest.test.js

Дата: 2026-05-10

Старый файл: develop (SHA 9ed5fbe0f)

Новый файл: наша ветка (SHA e67067aa7)

Код: draft43npm

Diff (1 строка)

4 it('base url', () => {
5 expect(baseURL)
6- .toBe('/rs');
7+ .toBe('');
7 });

Один символ: '/rs' → ''.

Старый тест проверял неверное значение у неверной переменной. Наглядно:

📦 Исходник (rest.js:10-11)
10  baseURL    = NODE_ENV === 'dev' ? 'localhost' : ''

11  baseRestURL = baseURL + '/rs'
Два разных экспорта. /rs добавляется к baseRestURL, не к baseURL.
❌ Старый тест (rest.test.js:6)
4  it('base url', () => {
5      expect(baseURL)      ← тест A...
6          .toBe('/rs');   ← ждал значение B!
7  });
Не та переменная + не то значение. '' === '/rs' — математически неверно.
✓ Исправленный тест (rest.test.js:6)
4  it('base url', () => {
5      expect(baseURL)
6          .toBe('');
7  });

Почему старый тест был неверен

Откуда взялся '/rs'? Это префикс REST API — определён в двух местах, которые должны совпадать:

СторонаФайлОпределениеРезультат
Бэкенд (Java) RestPaths.java:31 public static final String REST = "rs"; → Rest.URL = "/rs"
Фронтенд (JS) rest.js:11 export const baseRestURL = \`${baseURL}/rs\`; → "/rs" (когда baseURL = "")

Суффикс "/rs" живёт на baseRestURL — он никогда не был частью baseURL. Старый тест проверял значение baseRestURL у переменной baseURL — как если бы проверять window.location.pathname и ожидать значение window.location.host.

Старый исходник rest.js:10-11 (develop) определяет две разные переменные:

export const baseURL    = process.env.NODE_ENV === 'development' ? testServer : '';   // ← этот файл
export const baseRestURL = `${baseURL}/rs`;   // ← НЕ та же переменная

Старый тест rest.test.js:6 (develop) проверял:

expect(baseURL).toBe('/rs');    // ← ожидал значение baseRestURL на переменной baseURL

Это было неверно по двум причинам:

  1. Не та переменная. /rs — это значение baseRestURL (строка 11), а не baseURL (строка 10). Тест проверял суффикс у неправильного экспорта.
  2. Не то значение. Даже для baseURL правильное значение в тестовом режиме — '' (пустая строка), а не '/rs'. Доказательство:
ОкружениеКак задаётсяВыражение baseURLРезультат
Dev (npm start) CRA: NODE_ENV='development' 'development' === 'development' → true 'http://localhost:8080'
Test (npm test) CRA: NODE_ENV='test' — внедряется через react-scripts test 'test' === 'development' → false '' (пусто)
Production (npm run build) CRA: NODE_ENV='production' 'production' === 'development' → false '' (пусто)

В тестовом режиме выражение всегда равно ''. Старый тест expect(baseURL).toBe('/rs') проверял '' === '/rs' — математически неверно. Однако тест проходил годами.

Почему проходил? CRA's react-scripts test оборачивает Jest и может по-разному выставлять NODE_ENV в зависимости от версии. Возможно, в некоторых версиях CRA переменная не была надёжно установлена до выполнения теста — или тест был закеширован и не перезапускался после изменения исходника. В любом случае, утверждение было логически некорректным.

Исправление: В Vite import.meta.env.MODE всегда 'test' при vitest run. Исходник rest.js:10 (новый):

export const baseURL = (import.meta.env.DEV && import.meta.env.MODE !== 'test') ? testServer : '';

В тестовом режиме: DEV = false, MODE = 'test'. Выражение: false && ('test' !== 'test') → false. baseURL = ''. Новый тест rest.test.js:6 правильно ожидает ''.

Что тестирует остальной файл (без изменений, плюс новые тесты)

baseRestURL (строка 10)

Новый прямой тест: expect(baseRestURL).toBe('/rs'). Это выражение \`${baseURL}/rs\` — суффикс, который старый тест baseURL случайно проверял. Теперь тестируется явно.

handleHTTPErrors() (строки 14–26)

Новый describe-блок с тремя тестами для rest.js:32-38:

ТестВходОжиданиеЗачем
не-OK ответ (401) { ok: false, status: 401 } throws Error('Fetch failed: Error 401') Именно эту ошибку ожидает authentication.test.js:88 для неверного пароля
не-OK ответ (500) { ok: false, status: 500 } throws Error('Fetch failed: Error 500') Проверяет что сообщение использует реальный код статуса, а не захардкожен
OK ответ { ok: true, status: 200 } возвращает тот же объект без изменений Счастливый путь — функция пропускает успешные ответы

Использует expect(() => fn()).toThrow() — Vitest-паттерн, оборачивающий вызов для перехвата ошибки.

evalServiceURL() (строки 28–39)

Новый describe-блок тестирует сборщик URL rest.js:18-24. Три случая:

ТестВходОжидание
без параметровevalServiceURL('cakes/order')'cakes/order' — без изменений
с параметрамиevalServiceURL('cakes/order', { id: 1, amount: 123 })'cakes/order?id=1&amount=123'
URL уже имеет ?evalServiceURL('cakes/order?page=1', { amount: 10 })'cakes/order?page=1&amount=10' — использует разделитель &

Эта функция вызывается внутри getServiceURL() на rest.js:29. Ключевой тест — третий: проверяет что когда URL уже имеет параметры, новые добавляются через & (rest.js:20), а не через второй ?.

createQueryParams() (строки 42–55)