M

MLOG

Українська

Опануйте розробку через тестування (TDD) в JavaScript. Цей посібник охоплює цикл «Червоний-Зелений-Рефакторинг», практичну реалізацію з Jest та найкращі практики для сучасної розробки.

Розробка через тестування (TDD) в JavaScript: вичерпний посібник для глобальних розробників

Уявіть такий сценарій: вам доручили змінити критично важливу частину коду у великій застарілій системі. Ви відчуваєте страх. Чи не зламає ваша зміна щось інше? Як ви можете бути впевнені, що система все ще працює, як очікувалося? Цей страх змін є поширеною хворобою у розробці програмного забезпечення, що часто призводить до повільного прогресу та крихких додатків. Але що, якби існував спосіб створювати програмне забезпечення з упевненістю, створюючи страхувальну сітку, яка ловить помилки ще до того, як вони потраплять у продакшн? Це обіцянка розробки через тестування (Test-Driven Development, TDD).

TDD — це не просто техніка тестування; це дисциплінований підхід до проєктування та розробки програмного забезпечення. Він перевертає традиційну модель «написати код, потім протестувати». З TDD ви пишете тест, який не проходить, перед тим, як писати робочий код, щоб він пройшов. Це просте перевертання має глибокі наслідки для якості коду, дизайну та зручності супроводу. Цей посібник надасть вичерпний, практичний погляд на впровадження TDD в JavaScript, призначений для глобальної аудиторії професійних розробників.

Що таке розробка через тестування (TDD)?

За своєю суттю, розробка через тестування — це процес розробки, який покладається на повторення дуже короткого циклу. Замість того, щоб писати функціонал, а потім тестувати його, TDD наполягає на тому, щоб тест був написаний першим. Цей тест неминуче провалиться, оскільки функціоналу ще не існує. Завдання розробника — написати найпростіший можливий код, щоб цей конкретний тест пройшов. Після того, як він пройде, код очищується та покращується. Цей фундаментальний цикл відомий як «Червоний-Зелений-Рефакторинг».

Ритм TDD: Червоний-Зелений-Рефакторинг

Цей триетапний цикл є серцебиттям TDD. Розуміння та практика цього ритму є фундаментальними для опанування техніки.

Після завершення циклу для однієї невеликої частини функціоналу ви починаєте знову з нового тесту, що не проходить, для наступної частини.

Три закони TDD

Роберт С. Мартін (часто відомий як «Дядечко Боб»), ключова фігура в русі Agile, визначив три прості правила, які кодифікують дисципліну TDD:

  1. Ви не повинні писати жодного виробничого коду, крім як для того, щоб змусити пройти модульний тест, що не проходить.
  2. Ви не повинні писати більше коду модульного тесту, ніж достатньо для його провалу; і помилки компіляції є провалами.
  3. Ви не повинні писати більше виробничого коду, ніж достатньо для проходження одного модульного тесту, що не проходить.

Дотримання цих законів змушує вас слідувати циклу «Червоний-Зелений-Рефакторинг» і гарантує, що 100% вашого виробничого коду написано для задоволення конкретної, протестованої вимоги.

Чому варто впроваджувати TDD? Глобальний бізнес-кейс

Хоча TDD пропонує величезні переваги окремим розробникам, його справжня сила реалізується на рівні команди та бізнесу, особливо в глобально розподілених середовищах.

Налаштування середовища для TDD в JavaScript

Щоб почати роботу з TDD в JavaScript, вам знадобиться кілька інструментів. Сучасна екосистема JavaScript пропонує чудові варіанти.

Основні компоненти стеку для тестування

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

Покрокове налаштування за допомогою Jest

Давайте налаштуємо новий проєкт для TDD.

1. Ініціалізуйте ваш проєкт: Відкрийте термінал і створіть новий каталог проєкту.

mkdir js-tdd-project
cd js-tdd-project
npm init -y

2. Встановіть Jest: Додайте Jest до вашого проєкту як залежність для розробки.

npm install --save-dev jest

3. Налаштуйте скрипт тестування: Відкрийте ваш файл `package.json`. Знайдіть розділ `"scripts"` і змініть скрипт `"test"`. Також настійно рекомендується додати скрипт `"test:watch"`, який є неоціненним для робочого процесу TDD.

"scripts": {
  "test": "jest",
  "test:watch": "jest --watchAll"
}

Прапорець `--watchAll` наказує Jest автоматично перезапускати тести щоразу, коли файл зберігається. Це забезпечує миттєвий зворотний зв'язок, що ідеально підходить для циклу «Червоний-Зелений-Рефакторинг».

Ось і все! Ваше середовище готове. Jest автоматично знаходитиме файли тестів з іменами `*.test.js`, `*.spec.js` або розташовані в каталозі `__tests__`.

TDD на практиці: створення модуля `CurrencyConverter`

Давайте застосуємо цикл TDD до практичної, зрозумілої в усьому світі проблеми: конвертації грошей між валютами. Ми створимо модуль `CurrencyConverter` крок за кроком.

Ітерація 1: Проста конвертація за фіксованим курсом

🔴 ЧЕРВОНИЙ: Напишіть перший тест, що не проходить

Наша перша вимога — конвертувати певну суму з однієї валюти в іншу за фіксованим курсом. Створіть новий файл з ім'ям `CurrencyConverter.test.js`.

// CurrencyConverter.test.js
const CurrencyConverter = require('./CurrencyConverter');

describe('CurrencyConverter', () => {
  it('повинен коректно конвертувати суму з USD в EUR', () => {
    // Підготовка
    const amount = 10; // 10 USD
    const expected = 9.2; // Припускаючи фіксований курс 1 USD = 0.92 EUR

    // Дія
    const result = CurrencyConverter.convert(amount, 'USD', 'EUR');

    // Перевірка
    expect(result).toBe(expected);
  });
});

Тепер запустіть спостерігач тестів з вашого термінала:

npm run test:watch

Тест грандіозно провалиться. Jest повідомить щось на кшталт `TypeError: Cannot read properties of undefined (reading 'convert')`. Це наш ЧЕРВОНИЙ стан. Тест не проходить, тому що `CurrencyConverter` не існує.

🟢 ЗЕЛЕНИЙ: Напишіть найпростіший код для проходження тесту

Тепер давайте змусимо тест пройти. Створіть `CurrencyConverter.js`.

// CurrencyConverter.js
const rates = {
  USD: {
    EUR: 0.92
  }
};

const CurrencyConverter = {
  convert(amount, from, to) {
    return amount * rates[from][to];
  }
};

module.exports = CurrencyConverter;

Як тільки ви збережете цей файл, Jest перезапустить тест, і він стане ЗЕЛЕНИМ. Ми написали абсолютний мінімум коду, щоб задовольнити вимогу тесту.

🔵 РЕФАКТОРИНГ: Покращуйте код

Код простий, але ми вже можемо думати про поліпшення. Вкладений об'єкт `rates` трохи жорсткий. Наразі він достатньо чистий. Найважливіше, що у нас є робочий функціонал, захищений тестом. Перейдемо до наступної вимоги.

Ітерація 2: Обробка невідомих валют

🔴 ЧЕРВОНИЙ: Напишіть тест для невірної валюти

Що має статися, якщо ми спробуємо конвертувати у валюту, якої не знаємо? Ймовірно, має виникнути помилка. Давайте визначимо цю поведінку в новому тесті в `CurrencyConverter.test.js`.

// У CurrencyConverter.test.js, всередині блоку describe

it('повинен викидати помилку для невідомих валют', () => {
  // Підготовка
  const amount = 10;

  // Дія та Перевірка
  // Ми обгортаємо виклик функції в стрілкову функцію, щоб toThrow від Jest спрацював.
  expect(() => {
    CurrencyConverter.convert(amount, 'USD', 'XYZ');
  }).toThrow('Unknown currency: XYZ');
});

Збережіть файл. Запускач тестів негайно покаже новий провал. Він ЧЕРВОНИЙ, тому що наш код не викидає помилку; він намагається отримати доступ до `rates['USD']['XYZ']`, що призводить до `TypeError`. Наш новий тест правильно виявив цей недолік.

🟢 ЗЕЛЕНИЙ: Змусьте новий тест пройти

Давайте змінимо `CurrencyConverter.js`, щоб додати валідацію.

// CurrencyConverter.js
const rates = {
  USD: {
    EUR: 0.92,
    GBP: 0.80
  },
  EUR: {
    USD: 1.08
  }
};

const CurrencyConverter = {
  convert(amount, from, to) {
    if (!rates[from] || !rates[from][to]) {
      // Визначаємо, яка валюта невідома, для кращого повідомлення про помилку
      const unknownCurrency = !rates[from] ? from : to;
      throw new Error(`Unknown currency: ${unknownCurrency}`);
    }
    return amount * rates[from][to];
  }
};

module.exports = CurrencyConverter;

Збережіть файл. Тепер обидва тести проходять. Ми повернулися до ЗЕЛЕНОГО.

🔵 РЕФАКТОРИНГ: Очистіть код

Наша функція `convert` розростається. Логіка валідації змішана з обчисленнями. Ми могли б винести валідацію в окрему приватну функцію для покращення читабельності, але поки що це все ще керовано. Ключовим є те, що ми маємо свободу робити ці зміни, тому що наші тести скажуть нам, якщо ми щось зламаємо.

Ітерація 3: Асинхронне отримання курсів

Жорстке кодування курсів нереалістичне. Давайте проведемо рефакторинг нашого модуля, щоб отримувати курси із (замоканого) зовнішнього API.

🔴 ЧЕРВОНИЙ: Напишіть асинхронний тест, який мокує виклик API

По-перше, нам потрібно реструктуризувати наш конвертер. Тепер це буде клас, який ми можемо інстанціювати, можливо, з API-клієнтом. Нам також потрібно буде замокати API `fetch`. Jest робить це легко.

Давайте перепишемо наш тестовий файл, щоб врахувати цю нову, асинхронну реальність. Ми почнемо знову з тестування успішного сценарію.

// CurrencyConverter.test.js
const CurrencyConverter = require('./CurrencyConverter');

// Мокуємо зовнішню залежність
global.fetch = jest.fn();

beforeEach(() => {
  // Очищуємо історію моків перед кожним тестом
  fetch.mockClear();
});

describe('CurrencyConverter', () => {
  it('повинен отримувати курси та коректно конвертувати', async () => {
    // Підготовка
    // Мокуємо успішну відповідь API
    fetch.mockResolvedValueOnce({
      json: () => Promise.resolve({ rates: { EUR: 0.92 } })
    });

    const converter = new CurrencyConverter('https://api.exchangerates.com');
    const amount = 10; // 10 USD

    // Дія
    const result = await converter.convert(amount, 'USD', 'EUR');

    // Перевірка
    expect(result).toBe(9.2);
    expect(fetch).toHaveBeenCalledTimes(1);
    expect(fetch).toHaveBeenCalledWith('https://api.exchangerates.com/latest?base=USD');
  });

  // Ми також додали б тести на випадок збоїв API тощо.
});

Запуск цього призведе до моря ЧЕРВОНОГО. Наш старий `CurrencyConverter` не є класом, не має асинхронного методу і не використовує `fetch`.

🟢 ЗЕЛЕНИЙ: Реалізуйте асинхронну логіку

Тепер давайте перепишемо `CurrencyConverter.js`, щоб він відповідав вимогам тесту.

// CurrencyConverter.js
class CurrencyConverter {
  constructor(apiUrl) {
    this.apiUrl = apiUrl;
  }

  async convert(amount, from, to) {
    const response = await fetch(`${this.apiUrl}/latest?base=${from}`);
    if (!response.ok) {
      throw new Error('Не вдалося отримати курси валют.');
    }

    const data = await response.json();
    const rate = data.rates[to];

    if (!rate) {
      throw new Error(`Невідома валюта: ${to}`);
    }

    // Просте округлення для уникнення проблем з плаваючою комою в тестах
    const convertedAmount = amount * rate;
    return parseFloat(convertedAmount.toFixed(2));
  }
}

module.exports = CurrencyConverter;

Коли ви збережете, тест має стати ЗЕЛЕНИМ. Зауважте, що ми також додали логіку округлення для обробки неточностей з плаваючою комою, що є поширеною проблемою у фінансових розрахунках.

🔵 РЕФАКТОРИНГ: Покращуйте асинхронний код

Метод `convert` робить багато: отримує дані, обробляє помилки, парсить та обчислює. Ми могли б провести рефакторинг, створивши окремий клас `RateFetcher`, відповідальний лише за комунікацію з API. Наш `CurrencyConverter` тоді використовував би цей фетчер. Це відповідає Принципу єдиної відповідальності та робить обидва класи легшими для тестування та супроводу. TDD направляє нас до цього чистішого дизайну.

Поширені патерни та антипатерни TDD

Практикуючи TDD, ви відкриєте для себе патерни, які добре працюють, та антипатерни, що створюють тертя.

Хороші патерни, яких варто дотримуватися

Антипатерни, яких слід уникати

TDD у ширшому життєвому циклі розробки

TDD не існує у вакуумі. Він чудово інтегрується з сучасними практиками Agile та DevOps, особливо для глобальних команд.

Висновок: ваша подорож з TDD

Розробка через тестування — це більше, ніж стратегія тестування; це зміна парадигми в нашому підході до розробки програмного забезпечення. Вона виховує культуру якості, впевненості та співпраці. Цикл «Червоний-Зелений-Рефакторинг» забезпечує стабільний ритм, який веде вас до чистого, надійного та зручного для супроводу коду. Отриманий набір тестів стає страхувальною сіткою, яка захищає вашу команду від регресій, та живою документацією, яка допомагає в адаптації нових членів команди.

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

Почніть сьогодні. Виберіть одну невелику, некритичну функцію у вашому наступному проєкті та дотримуйтесь процесу. Напишіть тест першим. Спостерігайте, як він не проходить. Змусьте його пройти. І тоді, що найважливіше, проведіть рефакторинг. Відчуйте впевненість, яка приходить із зеленим набором тестів, і ви скоро здивуєтеся, як ви взагалі створювали програмне забезпечення інакше.