Что такое модульное тестирование и почему оно важно?
Модульное тестирование — это процесс написания и автоматического запуска тестов, чтобы гарантировать, что функции, которые вы кодируете, работают должным образом. Хотя это может показаться дополнительной работой, на самом деле речь идет о принятии превентивных мер для устранения ошибок до их появления.
Что такое модульный тест?
«Единица» — это наименьший возможный программный компонент в вашем приложении (т. е. функции, классы или компоненты). Отдельные модульные тесты гарантируют, что основной компонент вашего приложения ведет себя так, как ожидается, и что будущая фиксация в одной области вашего кода не нарушит код в другой. Если да, то, скорее всего, у вас есть ошибка либо в новом, либо в старом коде (или в плохо написанном/устаревшем тесте).
Цель модульных тестов очевидна — уменьшить количество ошибок, особенно ошибок, возникающих в результате интеграции. Разработчик может подумать, что локально все в порядке, и зафиксировать свой код только для того, чтобы узнать, что другая фиксация нарушила работу приложения. Модульное тестирование помогает выявить некоторые из этих дефектов до того, как они станут проблемами, и в сочетании с автоматизированными конвейерами непрерывной интеграции может гарантировать, что ежедневная сборка всегда работает правильно.
Модульное тестирование не ограничивается небольшими фрагментами кода; Вы также можете выполнять модульное тестирование более крупных компонентов, которые используют несколько других функций, которые сами могут быть протестированы. Это помогает более эффективно отслеживать ошибки — ошибка в методах большого объекта-компонента или в одном из других компонентов, которые он использует?
Хотя модульные тесты важны, они также не являются единственным тестированием, которое вы должны проводить. Запуск сквозного тестирования пользовательского интерфейса и ручная проверка вручную выявляют множество логических ошибок, которые модульные тесты могут пропустить, когда каждый модуль работает должным образом.
Модульное тестирование приводит к более чистой кодовой базе
Одной из основных проблем с унаследованными кодовыми базами является код динозавра — код настолько старый, что по сути представляет собой черный ящик, вы можете не знать, как он работает, но каким-то образом он работает, и вы не хотите рефакторить его из-за опасений, что он может все сломать.
В некотором смысле, когда вы пишете модульные тесты, вы пишете для них документацию. Возможно, вам не придется писать целое руководство, но вы всегда будете определять две вещи: что передать функции и что она возвращает, подобно тому, как вы определяете схему API. Благодаря этим двум битам информации становится ясно, что делает функция и как ее интегрировать в ваше приложение. Очевидно, что модульное тестирование не решает существующие унаследованные кодовые базы, но, в первую очередь, мешает вам писать этот тип кода динозавра.
Часто вы сможете написать свои тесты до фактической тестируемой функции. Если вы знаете, что должна делать ваша функция, написание теста сначала заставит вас подумать о конечном результате вашего кода и о том, за что он отвечает.
Если вам нравится этот эффект модульного тестирования, вас также может заинтересовать TypeScript — скомпилированный расширенный набор JavaScript, делающий его строго типизированным. Вы по-прежнему захотите писать модульные тесты, но знание того, какие типы дает и принимает функция, во время написания кода — очень полезная функция.
Как запускать модульные тесты
Существует множество различных фреймворков модульного тестирования, и тот, который вы в конечном итоге будете использовать, будет зависеть от тестируемого языка. Чтобы продемонстрировать, как они работают, мы будем использовать Jest, среду тестирования JavaScript, которая используется по умолчанию для новых приложений React.
Модульный тест обычно состоит из трех этапов:
- Упорядочить, где подготавливаются данные для тестирования устройства. Если вам нужно получить данные, построить сложный объект или просто настроить некоторые вещи, вы сделаете это в первую очередь.
- Действие, когда устройство вызывается, а ответ регистрируется.
- Утвердить, где происходит основная часть тестирования. Здесь вы пишете логические операции на основе
Если какое-либо из утверждений терпит неудачу, модуль не прошел тест, и вы получите подробный журнал и трассировку стека о том, что пошло не так, что вы ожидали и что на самом деле было возвращено.
В Jest есть множество разных сопоставителей, которые позволяют выполнять быстрые и простые утверждения. Например, у вас есть следующая функция, которая просто складывает два числа:
function doSomeMath(a, b) {
return a + b;
}Вы можете протестировать эту функцию с помощью следующего оператора:
test('Expect math to work', () => {
expect(doSomeMath(1, 1)).toBe(2);
});
Обычно это сохраняется вместе с функцией в functionName.test.js. Jest будет автоматически искать эти файлы при запуске тестов.
Функция .toBe() сопоставляется, в данном случае проверяя базовое равенство. Есть много других, таких как .toBeEqual(), который проверяет равенство объектов, и .toContain(), который проверяет содержимое массива. Вы можете прочитать документацию Jest для получения полного списка поддерживаемых ими сопоставителей.