Кратко и методично.
1) Первые проверки (быстрый фикс)
- Убедитесь, что тест возвращает промис/ждёт его: либо `return`, либо `await`. Пример правильного Jest-теста:
- `test('user has name', async () => { await expect(getUser($1$)).resolves.toHaveProperty('name'); });`
- Или: `return expect(getUser($1$)).resolves.toHaveProperty('name');`
- Используйте `expect.assertions($1$)` или `expect.hasAssertions()` чтобы гарантировать, что ассерции выполняются.
- Если `getUser` может кинуть синхронно — проверьте это отдельно.
2) Диагностика нестабильности (шаги)
- Изолируйте тест: запускайте только его (`.only` или `--testNamePattern`) и/или в одном процессе (`jest --runInBand`) — ищите взаимодействия между тестами.
- Логирование: временно вставьте `console.log`/trace внутри `getUser` и в тесте (вызовы, ответы, таймстемпы).
- Проверяйте тайм-ауты: в Jest по умолчанию тесты завершаются через 5 с; при необходимости увеличить `jest.setTimeout($10000$)` или передать третьим аргументом в `test`.
- Если в CI тесты падают, но локально нет — проверьте ресурсы/параллельность/переменные окружения.
3) Мокирование и контролируемые ответы
- Для unit-тестов мокируйте внешние зависимости:
- HTTP — `nock` или `fetch`/`axios` mock (`jest.mock('axios')`).
- БД — подставной in-memory (например `mongodb-memory-server`) или мок-модуль.
- Таймеры — `jest.useFakeTimers()` + `jest.runAllTimers()` / `jest.advanceTimersByTime($ms$)`.
- В Jest помните: fake timers не прокручивают микротаски автоматически; после `advanceTimersByTime` может понадобиться `await Promise.resolve()` или `await new Promise(process.nextTick)`.
- При моках используйте `jest.spyOn` / `mockImplementation` и не забывайте `jest.restoreAllMocks()` или `afterEach(() => jest.resetAllMocks())`.
- Мокируйте время/рандом: `jest.spyOn(Date, 'now').mockReturnValue(...)`, `jest.spyOn(Math, 'random').mockReturnValue(...)`.
4) Таймауты и таймеры
- Если асинхронная операция зависит от таймеров, используйте fake timers для детерминированности.
- Для сетевых/IO тестов предпочитайте реальные, но контролируемые тестовые инстансы (in-memory DB) и увеличьте таймауты для интеграционных тестов: `jest.setTimeout($15000$)`.
- Избегайте "магических" больших таймаутов для unit-тестов — лучше мокировать.
5) Контроль зависимостей и изоляция
- Внедрение зависимостей (dependency injection) упрощает мокирование и делает тесты детерминированными.
- Чистите состояние между тестами: `afterEach` — сбрасывайте БД, кэш, окружение.
- Используйте фикстуры/сиды для тестовой БД, фиксированные временные метки и однозначные идентификаторы.
6) Какие виды тестов и как их сочетать
- Unit tests: быстрые, изолированные, мокированные. Покрывают логику и ошибки (рекомендация: ~$70\%$-$80\%$ всех тестов).
- Integration tests: проверяют взаимодействие с реальной БД/сервисами (in-memory или тестовый стенд). Медленнее, покрывают сценарии, где важна интеграция (~$15\%$-$25\%$).
- E2E: проверяют полный поток в среде, близкой к продакшену; затратные и хрупкие — запускать реже (~$5\%$-$10\%$).
- Пороговое правило: как можно больше логики покрывать unit-тестами; интеграционные — на критичные сценарии; e2e — на ключевые пользовательские пути.
7) Практические советы на конкретный случай `expect(getUser(1)).resolves.toHaveProperty('name')`
- Исправьте тест на явное ожидание (`await` или `return`).
- Проверьте, что `getUser($1$)` действительно возвращает промис, а не undefined/синхронную ошибку.
- Мокируйте источник данных (например `userRepo.find`) и верните стабильный объект `{ name: 'Alice' }`.
- Добавьте тесты на случаи reject/ошибки: `await expect(getUser($999$)).rejects.toThrow()`.
Короткая чек-листа для отладки:
- Возвращается ли промис? (await/return)
- Нет ли гонки/глобального состояния между тестами? (runInBand, reset mocks)
- Мокированы ли внешние зависимости? (nock, mock DB)
- Управляются ли таймеры/время/рандом? (fake timers, mock Date/Math.random)
- Таймауты адекватны? (`jest.setTimeout($ms$)`)
- Логи/инструменты CI показывают отличия?
Если нужно, могу предложить конкретный патч к вашему тесту/мокам по реальному коду.