Мокування зовнішніх залежностей: підходи та антипатерни

Навіщо взагалі мокувати

Тести, які ходять у реальний платіжний шлюз або зовнішнє API геолокації, повільні, нестабільні і коштують грошей на кожен прогін. Мокування підміняє таку залежність передбачуваною заглушкою, яка повертає заздалегідь задану відповідь, що робить тест швидким і детермінованим. Детальніше про суміжний підхід можна прочитати в матеріалі «Property-based тестування на практиці».

Коли мокування шкодить

Головний антипатерн — мокувати те, чим сам код володіє, наприклад власний шар доступу до даних. Такий тест перестає перевіряти щось корисне: він підтверджує лише те, що мок викликається з очікуваними аргументами, а не те, що система дійсно працює правильно з реальною базою даних.

Інша небезпека — надмірне мокування внутрішньої логіки призводить до тестів, які ламаються при будь-якому рефакторингу реалізації, навіть якщо поведінка системи ззовні не змінилася. Розумне правило: мокувати варто межі системи — зовнішні сервіси, час, випадкові числа — але не власну бізнес-логіку, для якої краще використовувати реальний код і тестову (in-memory чи контейнеризовану) інфраструктуру. Ці ідеї перегукуються з темами «Contract-тестування мікросервісів» та «React Server Components і Vue Islands: що обрати у 2026».