Базовое введение в тестирование приложений React
Этот блог предназначен для абсолютных новичков, и здесь я собираюсь рассказать о строительных блоках тестирования реагирующих приложений с использованием Jest и ‘react-testing-library’.
Тестовый бегун
Тестовый файл обычно заканчивается .test.js или же .spec.js и он может иметь один или несколько тестов. Test Runner выведет список всех тестовых файлов, доступных в проекте, а затем проверит и отобразит статус «пройдено-не пройдено» для каждого из них. Конечно, мы можем ограничить программу запуска тестов, чтобы она обрабатывала только один тестовый файл или группу тестовых файлов.
Написание теста
Написание теста состоит из двух частей.
- Сначала нам нужно сказать в предложении или фразе, что мы собираемся тестировать. На самом деле это также служит документацией технических требований низкого уровня.
- Затем нам нужна тестовая функция с кодом для ее программного тестирования.
Тест завершится неудачно, если тестовая функция выдаст ошибку, и пройдет тест, если не выдаст ошибку.
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');
});
В приведенном выше коде мы можем протестировать много интересного.
- Мы имитируем событие нажатия кнопки, запрашивая текст, присутствующий в кнопке.
- Использование фиктивной функции (гдеИнкремент) мы проверяем, вызывается ли функция прослушивателя при нажатии кнопки.
- Мы ререндерим компонент и проверяем, правильно ли обновлен реквизит в лейбле.
Примечание. При повторном рендеринге компонент не создается заново. Это очевидно, поскольку мы по-прежнему можем использовать запрошенную переменную метки даже после повторного рендеринга и получаем обновленное значение.
Если у вас есть какие-либо вопросы или вы нашли какие-либо ошибки, пожалуйста, добавьте это в комментарий.