Базовое введение в тестирование приложений React

Этот блог предназначен для абсолютных новичков, и здесь я собираюсь рассказать о строительных блоках тестирования реагирующих приложений с использованием Jest и ‘react-testing-library’.

Тестовый бегун

Тестовый файл обычно заканчивается .test.js или же .spec.js и он может иметь один или несколько тестов. Test Runner выведет список всех тестовых файлов, доступных в проекте, а затем проверит и отобразит статус «пройдено-не пройдено» для каждого из них. Конечно, мы можем ограничить программу запуска тестов, чтобы она обрабатывала только один тестовый файл или группу тестовых файлов.

Написание теста

Написание теста состоит из двух частей.

  1. Сначала нам нужно сказать в предложении или фразе, что мы собираемся тестировать. На самом деле это также служит документацией технических требований низкого уровня.
  2. Затем нам нужна тестовая функция с кодом для ее программного тестирования.

Тест завершится неудачно, если тестовая функция выдаст ошибку, и пройдет тест, если не выдаст ошибку.

test('A sample test that fails', () => {
  if(2+3 !== 4){
    throw new Error('failed!');
  }
})

test('A sample test that passes', () => {
  if(2+2 !== 4){
    throw new Error('failed!');
  }
})

test('An empty test function always passes', () => {});

Библиотека утверждений

Библиотека утверждений помогает нам писать легко читаемые тестовые примеры. Хотя приведенные выше тесты действительны, их нелегко прочитать. Сравните его с приведенным ниже кодом.

test('A sample test that fails', () => {
  expect(2+3).toBe(4);
})

test('A sample test that passes', () => {
  expect(2+2).toBe(4);
})

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

Тестирование подразделяется на три типа: модульное тестирование, интеграционное тестирование и сквозное тестирование. При написании тестов очень важно быть практичным и прагматичным. Мы не должны пытаться охватить все возможности, потому что написание тестов требует времени. Еще одна проблема заключается в том, что в гибких средах и средах запуска требования могут часто меняться, и написанный тест устареет. Итак, нам нужно иметь некоторые рекомендации, а стратегия заключается в написании тестов.

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

test('test transform function', () => {
  expect(transform(input)).toBe(output);
}

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

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

Мы можем написать тесты для DOM, используя реагироватьДОМ библиотека. Допустим, у нас есть простой компонент счетчика.

const Counter = ({ count, onIncrement }) => (
  <div>
    <span>{count}</span>
    <button onClick={onIncrement}>+</button>
  </div>
);

Найдите ниже тест с использованием библиотеки reactDOM.

test('test Counter component', () => {
  const container = document.createElement('div');
  ReactTestUtils.render(
    <Counter count={5} onIncrement={() => {}} />,
    container
  );
  const incrementBtn = container.querySelector('button');
  expect(incrementBtn.textContent).toBe('+');
  const countDom = container.querySelector('span');
  expect(countDom.textContent).toBe('5');
});

Здесь мы проверяем, что компонент отображается правильно, а html-элементы имеют правильные метки. Но это только базовые тесты, и нам нужно больше тестов. Нам нужно имитировать действия пользователя, такие как нажатие кнопок, изменение состояния и реквизита.

Но при использовании reactDOM возможности ограничены. Таким образом, мы можем использовать ‘react-testing-library’. Это минималистичная библиотека, в ней легко писать и поддерживать тесты.

import { render, fireEvent, cleanup } from 'react-testing-library';
...

afterEach(cleanup);

test('test Counter component with react-testing-library', () => {
  let count = 5;
  const onIncrement = jest.fn(() => {
    count++;
  });

const { getByText, container, rerender } = render(
    <Counter count={count} onIncrement={onIncrement} />
  );

fireEvent.click(getByText(/\+/));
  expect(onIncrement).toHaveBeenCalledTimes(1);

let label = container.querySelector('label');
  expect(label.textContent).toBe('5');
  rerender(<Counter count={count} onIncrement={onIncrement} />);
  expect(label.textContent).toBe('6');
});

В приведенном выше коде мы можем протестировать много интересного.

  1. Мы имитируем событие нажатия кнопки, запрашивая текст, присутствующий в кнопке.
  2. Использование фиктивной функции (гдеИнкремент) мы проверяем, вызывается ли функция прослушивателя при нажатии кнопки.
  3. Мы ререндерим компонент и проверяем, правильно ли обновлен реквизит в лейбле.

Примечание. При повторном рендеринге компонент не создается заново. Это очевидно, поскольку мы по-прежнему можем использовать запрошенную переменную метки даже после повторного рендеринга и получаем обновленное значение.

Если у вас есть какие-либо вопросы или вы нашли какие-либо ошибки, пожалуйста, добавьте это в комментарий.

Похожие записи

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *