English for Jest Mocking

«Я насміхався з цього» використовується вільно для щонайменше трьох різних методів в Jest — гола функція насмішки, шпигун на реальній реалізації і повна функція насмішки модуля — і вибір неправильного терміна в перегляді коду ускладнює розуміння того, що тест насправді ізолює.

Ключовий словник

** Функція- ілюзія ** — функція, створена за допомогою jest.fn(), яка записує, як її було викликано (аргументи, кількість викликів) і повертає налаштоване значення, що замінює реальну залежність без виклику її фактичної поведінки.

• “Ми передаємо імітаційну функцію як зворотний виклик і стверджуємо, що вона була викликана точнісінько один раз з очікуваним вантажем, замість того, щоб покладатися на реальні побічні ефекти зворотного виклику.” *

** Spy ** — імітаційна функція, яка обгорнута навколо існуючої функції ( jest.spyOn ), яка може або зберегти початкову реалізацію, або замінити її, надаючи вам змогу спостерігати за викликами до реального методу без повного заміни його. “Ми використовували шпигун на методі error журналу, щоб ми могли стверджувати, що він був викликаний під час випадку невдачі, не приглушуючи всі інші реальні поведінки журналу.”

** Модуль мока ** — заміна всього імпортованого модуля на фальшиву реалізацію за допомогою jest.mock(), зазвичай використовується для ізоляції модуля під час тестування від залежності, наприклад, клієнта бази даних або бібліотеки HTTP. “Ми модифікували клієнта API, щоб тестування компонентів не робило справжніх мережевих викликів — воно просто повертає заготований відповідь, яку ми контролюємо.”

** Мок реалізація ** — особлива поведінка, налаштована для виконання мок функції при виклику, встановлена з mockReturnValue, mockResolvedValue або mockImplementation, визначає, що тест насправді виконує.

• “Ми встановили імітацію реалізації, яка викидає на другий виклик, щоб перевірити логіку повторних спроб без необхідності фактично викликати дві справжні помилки.” *

** Test double ** — загальний термін для будь- якого об’ єкта, який використовується замість реальної залежності під час тестування, включаючи моки, шпигунів, замітки і фальшивки як специфічні різновиди. “Моки, шпигунки і фальшивки - це всі види тестових подвійників - термін, який ви використовуєте, повинен відповідати тому, за яким ви насправді тягнетеся.”

Звичайні фрази

• Чи є це мокрою функцією, чи шпигун на реальній реалізації?»
• Чи ми модуль-нарікаємо на всю залежність, або просто заважаємо один метод?»
• Що ж робити, якщо виникають проблеми з цим тестом?
• Чи цей тестовий подвійний насправді необхідний тут, чи можемо ми безпечно використовувати реальну залежність?»
• Чи ми відновили мок між тестами, або стан протікає через них?»

Приклади висловлювань

Пояснення вибору тестової ізоляції у перегляді: “Ми повністю модулюємо платіжний клієнт, оскільки ми не хочемо, щоб будь-який тест вдарявся в реальний платіжний API - мокрою реалізацією просто повертається успішна відповідь на зарядку за замовчуванням, а окремі тести перезаписують її для випадків невдачі.”

Зневадження помилок тестів flaky: “Функція мока не була скинута між тестами, тому кількості викликів з попереднього тесту протікали в твердження наступного — додавання mockClear() в beforeEach виправило це.”

Перегляд надмірно імітованого тесту: “Це тестування настільки багато насміхається над модулем, що воно ледве перевіряє нашу реальну логіку — чи можемо ми використовувати шпигунів замість цього, щоб реальна реалізація все ще працювала і ми просто спостерігали за викликом?”

Професійні поради

• Використовуйте мок функцію спеціально для голого jest.fn() і шпигун для jest.spyOn() — розрізнення важливе, тому що шпигун може зберігати реальну поведінку, в той час як простий мок ніколи не робить.
• Скажіть module mock, коли замінена вся залежність, а не просто “ми зневажали її” - рецензенти повинні знати обсяг того, що підроблено, щоб судити, чи має сенс тест.
• Описувати мок-реалізацію явно, коли поведінка тесту залежить від неї — “мок повертає X” є більш корисним в описі PR, ніж просто “ми мокували залежність.”
• Використовувати ** test double ** як загальний термін, якщо особлива техніка не має значення для мети, але типово використовувати точний термін (моу, шпигун, стержень, підробка), коли це важливо.

Практичні вправи

1. Напишіть речення, яке відрізняє імітацію функції від шпигунства.
2. Поясніть, що замінює імітація модуля і чому ви її використовуєте.
3. Описати, чому скидання моделей між тестами має значення.

На практиці: навігація, зворотний зв’язок і співпраця

Ядро ефективного спілкування в професійному середовищі розробки не просто про те, щоб знати * що * тестувати; це про те, щоб сформулювати * чому * ви тестуєте його таким чином. Якщо ви використовуєте Jest з мокінгом, особливо під час надання зворотнього зв’ язку щодо запитів на витягування або участі у перегляді коду, ваші фрази значно впливають на те, як буде прийнято і реалізовано ваші пропозиції. Багато не-англомовних носіїв англійської вважають нюанси технічного словника викликом - зокрема, передаючи точний намір за мок-функцією проти шпигунства, або розуміння того, чому модуль моки може бути необхідним. Легко впасти в надмірно преписуючу мову, яка може відчувати себе як атака на чиїсь коди, а не конструктивний внесок.

Поширений сценарій виникає під час перегляду коду функції, що реалізує автентифікацію користувача. Розробник написав тест, який використовує jest.spyOn() на об’єкті AuthService, з метою перевірити, що його метод login викликається з певними параметрами. Однак, інший рецензент може відповісти: «Цього шпигунства недостатньо. Нам тут потрібен модельний модуль. AuthService залежить від декількох внутрішніх послуг — з’єднань з базами даних, логіки генерації токенів — і цей тест тільки ізольовує виклик входу в систему. Модуль мока дозволить нам повністю контролювати всі залежності, забезпечуючи, що ми тестуємо весь поток автентифікації, а не тільки взаємодію на поверхневому рівні. “Різниця полягає в * обґрунтуванні * за рекомендацією. Перший рецензент зосередився на конкретній спостережуваній поведінці (шпигун), в той час як другий підкреслив ширший архітектурний контекст і необхідність всеоб’ємної ізоляції. Використання фраз на кшталт «забезпечити повний ізоляцію» або «перевірити всі залежності» передає глибше розуміння принципів тестування, ніж просто вказуючи на неповну моку. Крім того, оформлення його як способу * поліпшити покриття тестування * часто більш смачним, ніж заява про те, що початковий підхід був «неправильним»

Інша ситуація включає повідомлення Slack, яке обговорює невдалий тест. Молодший розробник може набрати: « Функція getData не використовується належним чином ». Це може призвести до розчарування і захисної реакції. Краще було б сказати: «Я бачу періодичні невдачі з getData. Щоб допомогти нам визначити причину, чи можемо ми дослідити використовуючи модульну моделю для DataService? Таким чином, ми можемо систематично контролювати його повернені значення під час тестування і виключити будь- які потенційні проблеми, пов’ язані з зовнішніми джерелами даних. ” Зауважте, як цей підхід зосереджено на розв’ язанні проблеми (« визначити кореневу причину ») і пропонує конкретне рішення — модульне ігнорування — замість простої критики поточного стану.

Нарешті, при написанні PR-описів для тестів, що використовують моки, будьте ясно про те, що ви насміхаєтеся і чому. Не пишіть просто « Моковані залежності ». Замість цього описуйте конкретні аспекти залежності, яку слід контролювати: « Модуль мока створено для DatabaseConnection, щоб імітувати різні стани з’ єднання і забезпечити надійну обробку помилок під час отримання даних »

# Example using Jest to create a module mock for the DatabaseConnection class.
// Assuming you have a DatabaseConnection class defined elsewhere...
const { DatabaseConnection } = require('./database_connection'); // Replace with your actual path

jest.mock('./database_connection', () => ({
  getConnection: jest.fn(() => ({
    query: jest.fn((sql, params) => Promise.resolve({ rows: [{id: 1}] })), // Mock query function
    close: jest.fn()
  }))
}));

Цей приклад демонструє практичне застосування моделей модулів - керування поведінкою об’єкта DatabaseConnection для імітації різних сценаріїв під час тестування. Ключовим моментом є те, що точність і контекст є найважливішими при обговоренні Jest-насмішок з колегами, особливо з тими, чия перша мова не є англійською.