Как ты организуешь структуру тестов в проекте

1️⃣ Как кратко ответить

Организую структуру тестов, следуя принципам модульности и изоляции. Разделяю тесты на юнит-тесты, интеграционные и end-to-end тесты. Использую подход BDD для ясности и поддержки. Тесты располагаю рядом с тестируемым кодом или в отдельной папке tests, следуя соглашениям проекта.

2️⃣ Подробное объяснение темы

Организация структуры тестов в проекте — это важный аспект разработки, который помогает поддерживать качество кода и облегчает его поддержку. В Frontend-разработке тесты обычно делятся на три основных типа: юнит-тесты, интеграционные тесты и end-to-end (E2E) тесты.

Юнит-тесты проверяют отдельные функции или компоненты в изоляции. Они быстрые и помогают выявить ошибки на ранних стадиях разработки. Например, если у вас есть функция, которая складывает два числа, юнит-тест проверит, что она возвращает правильный результат для различных входных данных.

// Функция, которую мы тестируем
function add(a, b) {
  return a + b;
}
​
// Юнит-тест для функции add
test('adds 1 + 2 to equal 3', () => {
  expect(add(1, 2)).toBe(3);
});

• function add(a, b): Определение функции, которая принимает два аргумента и возвращает их сумму.
• test('adds 1 + 2 to equal 3', () => {...}): Определение теста с описанием, что он проверяет.
• expect(add(1, 2)).toBe(3): Проверка, что вызов функции add с аргументами 1 и 2 возвращает 3.

Интеграционные тесты проверяют взаимодействие между несколькими компонентами или модулями. Они помогают убедиться, что компоненты правильно работают вместе. Например, тест может проверить, что компонент формы правильно отправляет данные на сервер.

// Пример интеграционного теста
test('form submits data correctly', () => {
  const form = render(<FormComponent />);
  const input = form.getByLabelText('Name');
  const submitButton = form.getByText('Submit');
​
  fireEvent.change(input, { target: { value: 'John Doe' } });
  fireEvent.click(submitButton);
​
  expect(mockSubmitFunction).toHaveBeenCalledWith({ name: 'John Doe' });
});

• render(<FormComponent />): Рендеринг компонента формы для тестирования.
• fireEvent.change(...): Симуляция изменения значения в поле ввода.
• fireEvent.click(...): Симуляция нажатия на кнопку отправки.
• expect(mockSubmitFunction).toHaveBeenCalledWith(...): Проверка, что функция отправки была вызвана с правильными данными.

End-to-end тесты проверяют приложение целиком, от пользовательского интерфейса до базы данных. Они имитируют действия пользователя и проверяют, что приложение работает как ожидается. Например, E2E тест может проверить, что пользователь может успешно зарегистрироваться и войти в систему.

// Пример E2E теста с использованием Cypress
describe('User Registration', () => {
  it('allows a user to register and login', () => {
    cy.visit('/register');
    cy.get('input[name="username"]').type('newuser');
    cy.get('input[name="password"]').type('password123');
    cy.get('button[type="submit"]').click();
​
    cy.url().should('include', '/dashboard');
    cy.contains('Welcome, newuser');
  });
});

• cy.visit('/register'): Переход на страницу регистрации.
• cy.get('input[name="username"]').type('newuser'): Ввод имени пользователя.
• cy.get('button[type="submit"]').click(): Нажатие на кнопку отправки.
• cy.url().should('include', '/dashboard'): Проверка, что URL изменился на ожидаемый.
• cy.contains('Welcome, newuser'): Проверка, что на странице отображается приветственное сообщение.

Организация тестов в проекте может быть выполнена несколькими способами:

1. Рядом с тестируемым кодом: Тесты располагаются в тех же директориях, что и тестируемый код, но с расширением .test.js или .spec.js. Это облегчает навигацию и понимание, какие тесты относятся к какому коду.

2. В отдельной папке tests: Все тесты хранятся в отдельной папке, что может быть полезно для больших проектов, где важно отделить тесты от основного кода.

3. Смешанный подход: Использование обоих подходов в зависимости от типа теста или структуры проекта.

Использование подхода BDD (Behavior-Driven Development) помогает сделать тесты более читаемыми и понятными для всех участников проекта, включая не технических специалистов. Это достигается за счет использования описательных имен тестов и сценариев, которые отражают поведение системы с точки зрения пользователя.