Экономьте время и силы с React и React Native, выбирая подходящие инструменты тестирования.
Вы наконец-то решили приступить к тестированию с React - отлично! Это будет огромный шаг к написанию лучшего кода.
Сегодня я расскажу о различных решениях, касающихся тестирования, и о моем опыте их использования. В отличие от меня, вы сможете легко выбрать правильный инструмент для тестирования, не теряя времени.
Нет, эта статья будет не руководством о том, «как написать тест», а о том, «какие инструменты тестирования выбрать».
Типы тестов
Если вы не знакомы с тестированием, вы можете немного заблудиться. Существует много видов тестов ¹, но некоторые встречаются чаще.
Следующая статья от Atlassian является хорошей отправной точкой:
Поскольку мы сделаем наш первый шаг с тестированием React, наша сфера деятельности будет вращаться вокруг модульных и интеграционных тестов.
Различные инструменты
Теперь вам может быть интересно, с чего начать. Вы видели проект Node.js, в котором используется Jest, слышали о Mocha или Chai, но не знаете, о чем они.
Отлично, это именно то, что мы сегодня будем обсуждать. Чтобы получить более четкую картину, мы можем разделить разные виды инструментов, которые нам нужны.
Тестовые бегуны
У вас есть смутное представление о написании тестов, но как вы их организовываете и запускаете? Это роль тестировщиков. Некоторые из их функций:
- Поиск тестовых файлов и запуск тестов
- Сообщение об успехе или неудаче теста
- Настройка тестов для запуска или повторного запуска при обновлении
- Настройка среды
И многое другое.
Вот график, на котором сравниваются самые популярные программы запуска тестов Node.js при загрузке:
Утверждения
Теперь, когда у вас есть среда, в которой вы можете писать свои тесты, мы подходим к самому важному вопросу: Как мне написать свой первый тест?
Из нашей ранее процитированной статьи Atlassian говорит о модульных тестах следующее:
Они заключаются в тестировании отдельных методов и функций классов, компонентов или модулей, используемых вашим программным обеспечением.
С практической точки зрения вы можете рассматривать это как следующее:
- Получите результат от вашего индивидуального устройства (например, функции) в ситуации (с определенными параметрами).
- Убедитесь, что данный результат соответствует ожидаемому.
В этом суть утверждения: сравнение полученного результата с ожидаемым, чтобы сообщить о тесте как об успешном или неудачном.
Как и в случае с программами для запуска тестов, существует несколько библиотек, помогающих с утверждениями:
Шпионы
Модульное и интеграционное тестирование сопряжено с трудностями:
- Возможно, вы захотите провести модульное тестирование функции, которая зависит от внешней зависимости.
- Как для модульного, так и для интеграционного теста ваша функция может иметь внутреннюю зависимость, которую вы не можете использовать в среде JS.
- Ваша функция выполняет вызов API, но ваш сервер не настроен в вашей тестовой среде.
Вот где используются шпионы. Они помогают создавать подделки (или имитирующие объекты) и заменять зависимости определенным вами объектом.
Таким же образом вам могут помочь несколько шпионских библиотек:
Реагировать
Все предыдущие библиотеки вообще не имеют отношения к React. Их можно использовать для любого проекта JavaScript, но их недостаточно для тестирования React.
В React или React Native вы зависите от DOM или собственной мобильной среды. В базовой среде тестирования JavaScript у вас нет к ним доступа. Кроме того, с утверждениями в компонентах React может быть сложно работать.
Вот почему было введено несколько служебных библиотек: для использования React в вашей тестовой среде.
Сделать выбор
Отлично, теперь у вас есть общее представление о том, какие инструменты вам нужны, и список самых популярных из них. Теперь самое сложное: какие инструменты выбрать?
Тестовый бегун
Честно говоря, я никогда особо не рассматривал Jasmine, Ava и QUnit.
Сначала я начал тестирование с проектов Node.js. В то время более широко использовался мокко, это единственная причина, по которой я начал его использовать (вместе с Чай).
Mocha отлично работал несколько лет, а затем произошли два изменения:
- Я начал специализироваться на React
- Шут начал свергать Мокко
На этом этапе мне пришлось провести серьезное сравнение.
Mocha - это средство запуска тестов, которое позволяет вам выбрать внешнюю библиотеку утверждений и шпионскую библиотеку. Это не ограничивает вас, но дает больше гибкости
Jest - это полноценный фреймворк для тестирования, поставляемый с React и поддерживаемый Facebook. Из предыдущих разделов и графиков вы могли заметить: Jest - это не просто средство для выполнения тестов, оно включает в себя собственные библиотеки утверждений и фиктивных библиотек.
Интересно отметить, что Jest был построен на основе Jasmine.
Оба очень похожи. Конечно, их API меняются, и вам нужно привыкнуть к этому при переходе от одного к другому.
Я большой поклонник единой библиотеки / фреймворка / утилиты, которая выполняет заданную роль. Опробовав Jest и поэкспериментировав с React, я определенно принял его.
Рендерер
Чтобы протестировать React, мне пришлось выбирать между react-test-renderer, энзимом и библиотекой тестирования React (@ testing-library / реагировать).
react-test-renderer - это самая базовая служебная библиотека, поставляемая с React. Из документации React:
Этот пакет предоставляет средство визуализации React, которое можно использовать для визуализации компонентов React в чистые объекты JavaScript, независимо от DOM или собственной мобильной среды.
Библиотека тестирования React является частью семейства библиотек тестирования ², построена на основе react-test-renderer и представляет собой довольно легкое решение.
Он предоставляет утилиты для тестирования React и следует идее избегать тестирования деталей реализации ¹³.
Напротив, Фермент намного сложнее и тяжелее. Это дает вам гораздо больше функций, но не только к лучшему: становится слишком легко проводить тестирование деталей реализации.
Если вы не уверены, почему детали реализации тестирования принципиально плохи, я приглашаю вас узнать об этом больше.
Я работал со всем вышеперечисленным, Энзимом, очень долго. Как ни странно, сейчас я пользуюсь не той библиотекой.
Enzyme работал отлично, было немного сложно полностью настроить, но это все. После использования в течение некоторого времени я решил, что у меня есть следующие проблемы:
- Мне нужна была тяжелая конфигурация, чтобы заставить ее работать так, как я хотел.
- Свобода и функциональные возможности, предоставляемые Enzyme, позволили мне провести тестирование многих деталей реализации.
- Моя конфигурация время от времени ломалась при обновлении модулей.
Именно тогда я попробовал React Testing Library и теперь совершенно уверен: это библиотека тестирования, которая лучше всего соответствует моим потребностям.
- Намного более легкий процесс настройки / установки.
- Практически невозможно провести тестирование деталей реализации.
- У меня еще ни разу не было критического апгрейда.
- Существует Библиотека тестирования React Native для React Native.
Результат
Исходя из этого опыта, я теперь использую и рекомендую Jest ¹⁶ с утверждениями и имитациями благодаря Jest Expect ¹⁷ и Jest Mock Functions ¹⁸.
Библиотека тестирования React кажется лучшим решением для рендеринга компонентов React и дает вам несколько хороших API для работы с этими компонентами.
Бонус
Если вы работаете над приложением React, я уверен на 99,9%, что вы будете использовать вызовы API и Redux ¹⁹.
Если вы это сделаете, в какой-то момент вам нужно будет имитировать ответ API. Из всех доступных инструментов я бы рекомендовал использовать Nock.
На стороне Redux руководство по основным тестам доступно в официальной документации ²¹.
У вас могут возникнуть проблемы, если вы используете Redux-Saga ²². Вот действительно хорошая статья, охватывающая не только Redux-Saga, но и ее тестирование.
Потом
Я бы порекомендовал вам погрузиться в документацию Jest и React Testing Library (или React Native Testing Library ²⁴).
Когда вы поймете, как писать тесты, лучше всего будет написать отличные тесты.
Test Driven Development ²⁵ - это процесс разработки программного обеспечения, который определенно поможет вам в написании отличных тестов. Еще один полезный инструмент - Code Coverage ²⁶.
Я хотел бы завершить статью Atlassian о покрытии кода следующими словами:
Если охват вашего кода ниже 100%, можете быть уверены, что не все тестировали. Если это 100% ... вы не знаете.
Покрытие кода может сказать вам, был ли ваш код выполнен во время ваших тестов. Иногда вы заканчиваете выполнение кода, даже не тестируя его. Чтобы быть уверенным, что вы действительно все протестировали, необходимо прибегнуть к Mutation Testing ²⁹.
Мутационное тестирование - это замечательно, но очень дорого, и его нельзя использовать так часто, как модульное / интеграционное тестирование.
Приступая к тестированию, вы часто видите следующую пирамиду:
Это означает, сколько тестов вы должны пройти. Поскольку писать и запускать модульные тесты недорого, у вас должно быть их много.
По-прежнему дешевы, но меньше, чем модульные тесты: интеграционные тесты. Ожидается, что приложение будет иметь много интеграционных тестов, но меньше модульных.
Наконец, у вас будут тесты e2e, но в меньшем количестве, так как они дороги в настройке, написании и запуске.
Прежде чем погрузиться в сквозные тесты, вы можете узнать о функциональных тестах ³² и таких инструментах, как Cypress.
Удачи вам в тестировании.
Спасибо за прочтение.
Ищете практический курс по тестированию с React Native?
Также доступно на французском языке
- [1] Типы тестирования программного обеспечения: 100 примеров различных типов тестирования: https://www.guru99.com/types-of-software-testing.html
- [2] Различные типы тестирования в программном обеспечении | Atlassian: https://www.atlassian.com/continuous-delivery/software-testing/types-of-software-testing
- [3] тенденции npm - Jest vs Mocha vs Jasmine vs Ava vs QUnit: https://www.npmtrends.com/jest-vs-mocha-vs-jasmine-vs-ava-vs- qunit
- [4] npm тенденции - Jest vs Chai vs Assert vs Should vs Better-assert: https://www.npmtrends.com/jest-vs-chai-vs-assert-vs-should- против-лучше-утверждать-против-неожиданного
- [5] Макет объекта - Википедия: https://en.wikipedia.org/wiki/Mock_object
- [6] Тенденции npm - Jest vs Sinon vs Jack vs Testdouble: https://www.npmtrends.com/jest-vs-sinon-vs-jack-vs-testdouble
- [7] npm тенденции - реагирование-тест-рендерер против фермента против библиотеки тестирования React: https://www.npmtrends.com/react-test-renderer-vs-enzyme-vs- @testing -Библиотека / реагировать
- [8] Тенденции npm - Jest vs Mocha (5 лет): https://www.npmtrends.com/jest-vs-mocha
- [9] Mocha - забавная, простая и гибкая среда тестирования JavaScript (утверждения): https://mochajs.org/#assertions
- [10] Jest - восхитительное тестирование JavaScript: https://jestjs.io/en/
- [11] Test Renderer - React: https://reactjs.org/docs/test-renderer.html
- [12] Введение | Библиотека тестирования: https://testing-library.com/docs/
- [13] Подробности реализации тестирования: https://kentcdodds.com/blog/testing-implementation-details
- [14] Библиотека тестирования реакции: https://testing-library.com/docs/react-testing-library/intro
- [15] Фермент: https://github.com/enzymejs/enzyme
- [16] Шутка: https://jestjs.io/docs/en/getting-started
- [17] Jest Expect: https://jestjs.io/docs/en/expect
- [18] Функции Jest Mock: https://jestjs.io/docs/en/mock-functions
- [21] Redux: https://redux.js.org/
- [20] Нок: https://github.com/nock/nock
- [21] Написание тестов | Redux: https://redux.js.org/recipes/writing-tests
- [22] Redux-Saga: https://redux-saga.js.org/
- [23] Асинхронный с Redux-Saga: https://medium.com/swlh/asynchronous-with-redux-sagas-b43c9630f218
- [24] Библиотека тестирования React Native: https://testing-library.com/docs/react-native-testing-library/intro
- [25] Разработка через тестирование - Википедия: https://en.wikipedia.org/wiki/Test-driven_development
- [26] Охват кода - Википедия: https://en.wikipedia.org/wiki/Code_coverage
- [27] Разработка через тестирование с помощью библиотеки тестирования React: https://medium.com/make-it-heady/test-driven-development-tdd-with-react-testing-library-jest -906085418f
- [28] Введение в покрытие кода | Atlassian: https://www.atlassian.com/continuous-delivery/software-testing/code-coverage
- [29] Тестирование мутаций: https://en.wikipedia.org/wiki/Mutation_testing
- [30] Мутатор Страйкера: https://stryker-mutator.io/
- [31] Функциональное тестирование - Википедия: https://en.wikipedia.org/wiki/Functional_testing
- [32] Кипарис: https://www.cypress.io/
