предисловие
Эта статья является началом серии автоматизированного тестирования переднего плана, серия автоматизированных тестов будет проходить от теории к практике, действительно приведет нас к тому, чтобы узнать, как использовать среду автоматизированного тестирования переднего плана, и может упасть в бизнесе.
Прочитав всю серию, вы не будете использовать инструменты автоматизированного тестирования для повышения эффективности производства, приходите ко мне!
Количество лайков перевалило за 100. На следующей неделе будет обновлена комбинация фронтенд-автотестирования и React.Как это реализовать в проекте React.Приветствуем всех лайкать, комментировать и собирать! Ваша оценка - самая большая мотивация для моего письма!
Точка кипения ранее говорила, что Nuggets публикует только хорошие статьи с не менее чем 3 тыс. прочтений.Давайте посмотрим, сработает ли это на этот раз.
Тихо скажите, в конце статьи польза!
По известным причинам интерфейс, как специальное программное обеспечение с графическим интерфейсом, трудно автоматизировать тестирование. В бизнесе с быстрыми итерациями и большими изменениями пользовательского интерфейса реализовать автоматизированные тесты еще сложнее.
В недавнем учебном процессе я прочитал много статей, связанных с автоматическим тестированием интерфейса.Большинство из них рассказывают о том, как использовать фреймворки автоматизированного тестирования для тестирования фронтенд-кода, но редко объясняют, почему внедряется автоматизированное тестирование, в чем преимущества внедрения автоматизированного тестирования и какие проекты подходят для внедрения автоматизированного тестирования., но это действительно то, что мы хотим знать.
Учитывая, что читатели и отцы, возможно, не были знакомы с содержанием автоматизированного тестирования, эта статья начинается с основных концепций и основных способов использования, а также объясняет содержание автоматизированного тестирования для всех.
Прежде чем начать, проведите предварительную тренировку (она может быть длинной, если вам не нравится, можете перемотать вперед 🐶):
Восстановление сценария
Xiaowang — фронтенд-разработчик крупной отечественной фабрики. Буквально за неделю до разбора полетов продакт-менеджер выдал требование добавить новые функции в старый проект.
Ван открытый старый код проекта, ближайший взгляд, сердце медведя - компонент, который должен быть изменен до более чем 800 строк, быстрый взгляд, не нашел комментариев. AMY плакал, но менеджер по продукту на 3 дня, необходимый для достижения новых функций, не прибегайте, а кусать пулю и писать.
Сяо Ван собирался начать писать и провел общий технический анализ новых функций.Он обнаружил, что связь со старым кодом была относительно сильной, поэтому он начал писать, читать и модифицировать старый код одновременно.
Старый код был вонючим и длинным. Сяо Ван обнаружил, что там был кусок кода, который он не знал, зачем ему обрабатывать вводимый текст. Он думал, что это кусок бесполезного кода, и это также повлияло на его собственное дополнение новых функций, поэтому Сяо Ван удалил этот код.
Новая функция была завершена в соответствии с графиком. Сяо Ван прошел простую ручную самопроверку, и проблем не возникло, поэтому он отправил тестовое электронное письмо, дождался результатов теста и с радостью приготовился к разбору полетов.
Тестирование новой функции также прошло гладко: Сяо Ван запустил новую функцию онлайн, закончил свою работу на этой неделе и отправился домой, чтобы насладиться выходными.
Сяо Ван рано умылся и лег спать, и вдруг посреди ночи позвонил начальник: Сяо Ван, вставай, там баг, который затрагивает 1w+ пользователей, вставай и смотри, в чем проблема!
Сяо Ван внезапно встал, достал из рюкзака компьютер и начал выяснять причину бага, после отладки он обнаружил, чтоОказалось, что старый код, который я удалил, вызвал ошибку.!
Сяо Ван снова заплакал, исправил баг и срочно выпустил.
"Я отчитаюсь на работе в следующий понедельник. Если сегодня будет такой баг, то премия по итогам года точно пропадет, а общее обследование тоже зависнет. Мне нужно написать отчет о ситуации и разослать его в большинство отделов. , это позор».
Но если бы в старом проекте компании вводилось автоматизированное тестирование, история позже была бы совсем другой:
Разворот сценария
Сяо Ван собирался начать писать и провел общий технический анализ новых функций.Он обнаружил, что связь со старым кодом была относительно сильной, поэтому он начал писать, читать и модифицировать старый код одновременно.
В front-end разработке старого проекта для обеспечения нормальной работы проекта был прописан код юнит-теста и интеграционного теста, в README от коллег по обслуживанию требовалось запустить тест-кейс после добавления /изменение кода.
Старый код был вонючим и длинным. Сяо Ван обнаружил, что там был кусок кода, который он не знал, зачем ему обрабатывать вводимый текст. Он думал, что это кусок бесполезного кода, и это также повлияло на его собственное дополнение новых функций, поэтому Сяо Ван удалил этот код.
Сяо Ван запустил тестовый пример после удаления кода, и внезапно в поле зрения появилось несколько ослепительно красных символов——FAIL TO TEST
Глядя на описание тестового случая, Сяо Ван знал назначение этого кода. Итак, Сяо Ван провел рефакторинг этого кода, добавил новые функции и запустил тестовые примеры — все зеленые.PASS.
Сяо Ван вздохнул с облегчением, добавил тестовые сценарии к своим новым функциям и внес изменения, чтобы новые тестовые сценарии работали.
Хотя Сяо Ван немного работал сверхурочно из-за написания тестовых примеров, он чувствовал себя расслабленным и в полной безопасности.
Все тестирование и публикация прошли нормально, Сяо Ван наслаждался приятными выходными.
После возвращения на следующей неделе отчитаюсь на работе.Я в хорошем настроении и в отличном состоянии.Меня ценит начальство. Оценка производительности — это здорово, награды в конце года и общие опросы — не проблема.
Вышеописанные истории все мои ГГ, любое сходство чисто случайно 🐶.
Что такое тест?
Тестирование — это фактически использование поверх уже разработанного программного обеспечения.Ручной или не ручнойСпособ проверки того, соответствует ли программное обеспечение инженерным ожиданиям и не вызовет ли оно потенциальных проблем, таких как потери пользователей/разработчиков.
В большинстве случаев код внешнего интерфейса, который мы пишем, разрабатывается путем ручного самотестирования или вручную тестируется специализированными тестировщиками после тестирования.
Конечно, с ручным тестированием проблем нет, но с помощью инструментов автоматизированного тестирования проблему можно обнаружить быстрее, эффективнее и точнее.
Автоматическое тестирование фактически запускает часть тестового кода, чтобы убедиться, что целевой код соответствует определенному ожиданию.
В оставшейся части этой статьиТермин «тестирование» будет конкретно относиться к автоматизированному тестированию..
Зачем тестировать?
Цель нашего тестирования состоит в том, чтобы обнаружить ошибки во времени, улучшить качество и эффективность качества и развития кода и избежать потерь, вызванных выбросом кода с ошибками.
Преимущество автоматизации тестирования заключается в том, что обратная связь является своевременной, что может значительно повысить эффективность разработки внешнего интерфейса.
В нашем ежедневном процессе разработки нам часто приходится вручную проверять, могут ли определенные операции или процессы нормально работать после запуска проекта? Часто ли необходимо прерывать точки или использоватьconsole.logПросмотр сообщений консоли, чтобы проверить, выполняется ли функция?
Эти сценарии, которые требуют от нас ручной проверки соответствия результатов выполнения кода ожиданиям, могут быть заменены автоматизированными тестовыми сценариями.
Многие существующие зрелые автоматизированные среды тестирования могут полностью имитировать наши ручные операции и использовать сценарии для автоматического запуска тестовых случаев.Обычно требуется всего несколько секунд, чтобы дать точную обратную связь, и в то же время он также может прослушивать изменения кода и автоматически выполнять то, что происходит в проекте.Тестовые случаи, соответствующие измененному коду, могут значительно повысить эффективность нашей разработки.
В то время, когда бизнес и персонал компании быстро меняются, польза от написания сценариев автоматизированного тестирования становится все выше и выше. Разработчикам больше не нужно бояться вносить регрессионные ошибки и больше не нужно бояться передавать свой код другим для обслуживания. С ограничениями тестового сценария итерация/рефакторинг могут быть более неторопливыми.
Какие виды тестов существуют?
Фронтенд-тестирование в основном делится на 3 типа:Модульный тест,Интеграционный тест,Тест пользовательского интерфейса
Пропорции трех тестов:
Реальность такова, что пирамида тестирования большинства компаний перевернута, и ее проводят люди.тестирование пользовательского интерфейсаВместо этого наиболееИнтеграционное тестированиеа такжемодульный тестНо в основном игнорировали.
Модульный тест
Модульное тестирование реализовать проще всего: библиотеки классов инструментов, совместно используемые несколькими компонентами в коде, подкомпоненты, совместно используемые несколькими компонентами, и т. д.
Обычно в общедоступных функциях/компонентах должны быть модульные тесты, чтобы убедиться, что код работает правильно. Юнит-тесты также должны быть самыми большими и наиболее охватываемыми в проекте.
Функции/компоненты, которые можно тестировать, должны иметь низкую связанность, что также в определенной степени обеспечивает качество нашего кода.
Интеграционный тест
Интеграционное тестирование обычно применяется к: функциям/компонентам с высокой степенью связанности, функциям/компонентам, прошедшим вторичную инкапсуляцию, функциям/компонентам, состоящим из нескольких функций/компонентов и т. д.
Целью интеграционного тестирования является проверка правильности работы различных объединенных модулей после модульного тестирования. Будет проверено общее воздействие комбинированного кода на внешний интерфейс, чтобы убедиться, что комбинированный код работает должным образом.
Интеграционное тестирование — это тест с высоким уровнем безопасности, который может значительно повысить доверие разработчиков.Разумный дизайн интеграционных тестовых случаев и прохождение тестов могут гарантировать, что продукт в значительной степени соответствует ожиданиям.
Тест пользовательского интерфейса
В процессе изучения и обращения к литературе я обнаружил, что многие отечественные статьи путают UI-тест (UI Test) и end-to-end тест (E2E Test), думая, что это один и тот же тип теста.
Фактически, тест пользовательского интерфейса (тест пользовательского интерфейса) и концептуальный тест (E2E тест) немного отличается:
Тест пользовательского интерфейса (UI Test) предназначен только для внешнего тестирования, которое отделено от реальной внутренней среды.Он просто запускает интерфейс в реальной среде, а серверная часть и данные должны использовать Mock.
Сквозное тестирование (E2E Test) — это запуск всего приложения в реальной среде, включая данные, которые также должны быть реальными.
Что касается внешнего интерфейса, UI Test ближе к нашему процессу разработки. В режиме разработки с разделением интерфейсной и серверной частей для фронтальной разработки обычно используются сервер и данные Mock. Поэтому нам необходимо провести соответствующий тест пользовательского интерфейса (UI Test) после того, как разработка в основном завершена.
Степень автоматизации тестирования пользовательского интерфейса невысока, и большинство также полагаются на ручное тестирование.
В некоторых инструментах автоматизированного тестирования есть функция создания снимков, что также может помочь нам в определенной степени добиться автоматизации UI Test (UI Test).
Какой проект по внедрению автоматизированного тестирования?
В большинстве статей на маркете об этом вопросе не говорилось, но на самом деле над этим вопросом стоит задуматься больше всего!
В химии есть известная поговорка:
Говорить о токсичности помимо дозы - хулиганство.
Точно так же в автоматизированном тестировании переднего плана было бы глупо говорить о преимуществах и необходимости автоматизированного тестирования в отрыве от типов проектов, штата разработчиков программного обеспечения и жизненного цикла.
Лично я предпочитаю писать тестовый код, когда вижу, что все тест-кейсы зеленые, мне очень комфортно.
Но я предполагаю, что большинство разработчиков почувствуют, что требований так много, настолько срочных, что очень сложно гарантировать, что требования выполнены, и нет сил писать тестовый код.
На самом деле мы часто разрабатываем какие-то одноразовые модули кода для некоторых действий.Такой модуль кода отличается простотой, а впоследствии итерации продолжаются мало, этот код совершенно не нужен для внедрения инструментов автоматизации тестирования.
Сценарии, подходящие для внедрения автоматизированных тестов:
- Разработка и поддержка классов публичных библиотек
- Итерация/рефакторинг для среднесрочных и долгосрочных проектов
- Ссылки на неконтролируемые сторонние зависимости
Эти сценарии требуют введения автоматизированных тестов для ограничения существующего кода.Особенно для среднесрочных и долгосрочных проектов сложно вернуть человеческие ресурсы во время итерации/рефакторинга, поэтому автоматизированное тестирование особенно важно!
Как выбрать тестовый инструмент?
Сейчас на рынке много популярных инструментов для тестирования, но есть общая проблема:Поддержка новых функций отстает.
Фреймворк тестирования интерфейса можно описать как сто распустившихся цветов.
- Модульные тесты включают Mocha, Ava, Karma, Jest, Jasmine и т. д.
- Тест интеграции и тест на интерфейс ui включают Reacttestutils, тестирование рендеринга, фермент, реагировать-тестирование-библиотеку, VUE-Test-Utils и т. Д.
Сравнение основных инструментов тестирования
| Рамка | утверждение | моделирование | снимок | Асинхронное тестирование |
|---|---|---|---|---|
| Mocha | Не поддерживается по умолчанию, можно настроить | Не поддерживается по умолчанию, можно настроить | Не поддерживается по умолчанию, можно настроить | дружелюбный |
| Ava | Поддержка по умолчанию | Не поддерживается, требуется сторонняя конфигурация | Поддержка по умолчанию | дружелюбный |
| Jasmine | Поддержка по умолчанию | Поддержка по умолчанию | Поддержка по умолчанию | недружелюбный |
| Jest | Поддержка по умолчанию | Поддержка по умолчанию | Поддержка по умолчанию | дружелюбный |
| Karma | Не поддерживается, требуется сторонняя конфигурация | Не поддерживается, требуется сторонняя конфигурация | Не поддерживается, требуется сторонняя конфигурация | Не поддерживается, требуется сторонняя конфигурация |
Mocha
- Mocha — лучшая экологическая и наиболее широко используемая среда для одиночного тестирования, но для достижения высокой масштабируемости требуется дополнительная настройка.
Ava
- Ava — это более легкий, эффективный и простой фреймворк для одиночного тестирования, но он недостаточно стабилен сам по себе и перегружает ЦП при наличии большого количества одновременно запущенных файлов.
Jasmine
- Jasmine — «старичок» фреймворка одиночного тестирования, работает «из коробки», но поддержка асинхронных тестов слабая.
Jest
- Jest основан на Jasmine, с множеством модификаций и добавлением многих фич, тоже работает «из коробки», но хорошо поддерживает асинхронное тестирование.
Karma
- Karma можно протестировать в реальных браузерах, мощных адаптерах, а также настроить с помощью других одиночных сред тестирования, обычно используемых с Mocha или Jasmine.
У каждого фреймворка есть свои преимущества и недостатки, нет лучшего фреймворка, есть только самый подходящий фреймворк. Средой тестирования по умолчанию для августа является Karma + Jasmine, а средой тестирования по умолчанию для React — Jest.
Jest рекомендуется и используется различными приложениями React. Он основан на Jasmine и до сих пор претерпевал значительные изменения и добавлял множество функций. Недавно созданный проект Create React App будет настроен с Jest по умолчанию, и мы можем использовать его напрямую, не внося слишком много изменений.
Какие тестовые идеи использовать?
TDD: разработка через тестирование
- TDD: разработка через тестирование (Test-Driven Development): TDD требует написания тестового кода перед написанием кода для определенной функции, а затем написания только кода функции, которая обеспечивает прохождение теста, и продвижение всей разработки посредством тестирования.
BDD: развитие, основанное на поведении
- BDD: Behavior-Driven Development (Разработка, управляемая поведением): BDD позволяет участникам проекта (даже тем, кто не знаком с программированием) использовать естественный язык для описания функций системы и бизнес-логики, чтобы проводить тестирование автоматизации системы в соответствии с этими этапами описания.
Базовый синтаксис Jest
Поскольку крупные производители обычно используют React/Vue для разработки, а официальными инструментами модульного тестирования, рекомендованными React/Vue, являются Jest, в этой статье мы кратко представим основной синтаксис Jest.
сопоставитель
Number
String
Array & Iterable
Exception
Асинхронное тестирование кода
крючки жизненного цикла
Порядок выполнения хуков жизненного цикла соответствует луковой модели.
исполнительный лист
Порядок выполнения тестового блока/кейса аналогичен асинхронной очереди.
Функция макета
резюме
В этой статье представлены некоторые основные концепции автоматизированного тестирования переднего плана и основы использования основного фреймворка тестирования Jest.
Я считаю, что после прочтения этой статьи у вас должно быть определенное представление об автоматизированном тестировании интерфейса.
Следующая статья, набравшая более 100 лайков, расскажет вам о сотрудничестве между средой автоматизированного тестирования Jest и React, чтобы каждый мог по-настоящему реализовывать проекты React и повышать эффективность производства!
Благосостояние в конце статьи
В последнее время я видел, что осенний набор на некоторые крупные фабрики начался заранее, и там слишком много внутренних push-кодов.
Как всем известно, даже если у вас есть внутренний push-код и вы отправляете резюме, вы можете пропустить большую фабрику по разным причинам, таким как неадекватное составление резюме и отсутствие навыков на собеседованиях!
Сфокусируйся наHello FE, который имеетОчень подробная большая заводская серияПодвел итоги опыта различных производителей Big Brothers!