Эта статья разделена на 2 части:
- Что такое JS-тесты? (Часть 1)
-« Какие инструменты можно использовать? (Часть 2)"
Оригинальную статью, написанную на французском, можно найти здесь: Комментарий« bien tester une application javascript? (часть 1) | Джеффри Лаллоу | Середина"
Слишком часто забывают, но никогда не бесполезно
За считанные минуты вы можете опубликовать новое приложение javascript в Интернете, в мобильных магазинах или в репозитории git.
Распространение JS-фреймворков еще больше упрощает разработку интерфейсного приложения, требует все меньше и меньше времени и ресурсов, и, к сожалению, мы часто забываем одну важную вещь: правильно протестировать ваше приложение, прежде чем запускать его в производство.
При всей этой простоте разработки вы можете не осознавать, что если вы протестируете свое приложение с самого начала, это сэкономит вам много времени на исправлениях впоследствии ...
Это практическое руководство поможет вам правильно разработать приложение JavaScript, опубликовать его с уверенностью в качестве и показать своему начальнику, что вы больше, чем просто программист. !
Что такое фронт-тесты JS?
Если вас спросят, из чего состоит реализация стратегии внутреннего тестирования, каждый может привести пример: модульные тесты, тестирование API, тесты производительности, нагрузочные тесты и т. Д.
Всем кажется очевидным (на самом деле это должно быть…) протестировать серверную часть, потому что в большинстве случаев бизнес-логика находится в коде.
Так что насчет внешнего тестирования и есть ли в нем польза? Если вы прочтете эту статью, вы сможете представить себе ответ:
ДА, можно настроить стратегию тестирования на передней стороне приложения, и это даже необходимо!
Как и в случае с серверной частью, интерфейсные приложения могут настраивать большое количество одинаково полезных типов тестов:
- Модульные тесты: единичная проверка поведения функции.
- Функциональные тесты: проверьте правильность варианта использования, определенного в спецификациях проекта.
- Стресс-тесты: проверьте поведение сайта за пределами ожидаемой нагрузки.
- Нагрузочные тесты: убедитесь, что функция остается доступной, несмотря на большое количество подключений к ней.
- Контрольные тесты: неоднократно проверяйте, может ли пользователь получить доступ к функциям сайта.
- Тесты безопасности: убедитесь, что информационная система защищает данные и поддерживает функции, как задумано.
- Тесты передовой практики: проверьте соответствие передовому опыту разработки современного веб-сайта.
- Тесты доступности: проверьте соответствие стандартам и стандартам доступности для доступа к вашему веб-сайту как можно большему количеству людей.
- Пользовательские тесты: проверьте удовлетворенность целевой аудитории (не путать с удовлетворенностью клиентов).
- …
Хорошо, но как узнать, какие тесты реализовать?
Определите стратегию тестирования
Первое, что нужно сделать, это определить стратегию тестирования, которую нужно установить. Цель состоит не в том, чтобы тестировать для развлечения, а в том, чтобы протестировать эффективно.
Несколько вопросов, которые следует задать себе перед тем, как начать:
- Каков уровень критичности моего приложения?
- Какой бюджет у моего проекта?
- Каков ожидаемый уровень производительности?
- Есть ли у меня бизнес-код в моем интерфейсном приложении?
- Насколько большим будет исходный код моего приложения после публикации?
- Есть ли у меня крайний срок по контракту для исправления и восстановления услуги?
- Каков уровень знаний о «тестах» моей проектной команды?
Как только на эти вопросы будут даны ответы, у вас будет более четкое представление о том, что реализовать в своем интерфейсном приложении.
Следующим шагом будет перечисление ваших типологий тестов, которые вы хотите реализовать в качестве приоритетных в вашем проекте.
Лично я хотел бы расставить приоритеты тестов в следующем порядке, по важности и в соответствии с затратами на внедрение и рентабельностью инвестиций (окупаемость инвестиций):
Чтобы помочь вам в выборе типологий тестов для настройки, вот несколько ключей, которые помогут вам ответить на вопросы, заданные выше:
1: Критичность
Очевидно, что между веб-сайтом вашей сестры и приложением Twitter PWA не будет одной и той же артиллерии.
Вы должны знать, как поставить курсор в нужное место. но чаще всего этот курсор уже указан в спецификациях проекта, надо только хорошо его интерпретировать.
В зависимости от критичности проекта приоритизация реализации тестовых типологий может немного отличаться.
Выбор типологий тестов также должен производиться в соответствии с потребностями проекта:
- Если проект обрабатывает конфиденциальные данные, необходимо будет расставить приоритеты для тестов безопасности.
- Если проект предназначен для публичного рынка, доступность будет обязательной и, следовательно, может быть приоритетной.
- Если приложение используется очень большим количеством пользователей, возможно, потребуется отдать предпочтение нагрузочным тестам или стресс-тестам.
2 : Бюджет
К сожалению, очень часто именно этот момент определяет стратегию тестирования. Чем больше бюджет, тем больше вы можете настраивать разные типы тестов.
Пользовательское и модульное тестирование должно быть минимумом, реализованным в любом проекте.
Это также тесты с самым высоким ROI. Эффективность этих тестов позволит значительно сэкономить время в конце проекта и на этапе приемки за счет сокращения количества регрессий, аномалий и, следовательно, количества обменов с заказчиком.
Настроить передовые тесты недорого, поэтому стоит добавить их в свою стратегию.
Для других типов тестов они, как правило, более дорогие.
Вам решать, применять ли эти тесты для всего приложения или использовать некоторые функции, чтобы снизить стоимость и в соответствии с потребностями и потребностями. критичность проекта.
3: Ожидаемый уровень производительности
Будет ли ваше приложение использовать 100 пользователей или 1 миллион? Через сколько секунд должна открыться страница вашего сайта, чтобы она оставалась подходящей для времени? Каким может быть пик использования в течение 1 часа или за один раз T?
Это типы вопросов, которые необходимо задать перед началом проекта. Даже если это будут только оценки, они окажут сильное влияние на архитектуру проекта и стратегию тестирования, которая будет реализована.
Чем выше ожидания от производительности вашего приложения, тем более строгими должны быть тесты.
Следующие типы тестов идеально подходят для решения этих проблем:
- Стресс тест
- Нагрузочный тест
- Контрольный тест
Но нет ничего лучше, чем организовать пользовательские тесты перед производством, чтобы получить объективную обратную связь о производительности приложения.
4: Бизнес-код - соотношение пользовательского интерфейса
Мы не собираемся лгать друг другу, бесполезно все тестировать во внешнем приложении (тогда как на стороне серверной части вопрос могло возникнуть).
Если вы хотите реализовать модульные тесты, делайте это только для бизнес-кода вашего приложения.
Нет (или очень мало) добавленной стоимости для тестирования приложения, которое отображает только результат, полученный веб-службой. Если это ваш случай, может быть лучше настроить некоторые внутренние тесты API, которые будут более эффективными при проверке достоверности данных.
С другой стороны, если ваше приложение обрабатывает данные, преобразует их, управляет локальной базой данных, использует сервис-воркеры, формы и т. д., то модульные тесты приобретают все свое значение!
Точно так же, если ваше приложение предлагает пользователям только одну страницу, возможно, не стоит настраивать функциональные тесты. Вы бы потратили больше времени на настройку механизма тестирования, чем на написание самих тестов.
Но чем больше в вашем приложении страниц и функций, тем больше будет смысла в функциональных или пользовательских тестах.
5: Размер исходного кода
Как и в предыдущем пункте, если ваш исходный код состоит всего из 50 строк, действительно ли необходимо настраивать полный механизм тестирования?
Внедрение тестов требует затрат, поэтому вам понадобится минимум материала для тестирования, чтобы усилия по внедрению были рентабельными.
Чем больше у вашего приложения большого исходного кода, тем более значимыми будут тесты, потому что тем выше риск регрессии.
Это верно для существующих приложений, но также и для приложений, функциональность которых, вероятно, вырастет позже.
Если исходный код вашего проекта важен (или будет) важен, необходимо внедрить модульные тесты и тесты передового опыта, чтобы сократить технический долг и, следовательно, сэкономить время и деньги в дальнейшем.
6: Сроки исправления по контракту
В контрактах с клиентами очень часто указываются сроки исправления аномалий, о которых сообщается в их приложениях (например: 2 часа для ошибки блокировки, 1 день для серьезной ошибки, 5 дней для мелкая ошибка и т. д.)
Это влияет на вашу стратегию тестирования.
Чем короче крайние сроки, тем более активными вы должны быть и тем важнее будут тесты для мониторинга, составления отчетов, идентификации и анализа вашего приложения.
Если модульные тесты выполнены правильно, вы сможете очень быстро убедиться, что регрессия не происходит в рабочем приложении.
Контрольные тесты также позволяют предвидеть аномалии, сообщая о проблеме доступа к функции, а также с помощью функциональных тестов.
7: Знание моей проектной группы
Последний важный, но не менее важный момент: знает ли ваша проектная группа о тестах, которые нужно внедрить?
Если да, то все в порядке, проект в надежных руках!
Если это не так, важно включить в свою стратегию развитие командных навыков: либо через обучение, либо через сопровождение опытного человека или услуги.
Также может потребоваться исключить определенные типы тестов, если никто не знает, как их настроить, и переориентировать внимание на другие типы тестов.
Когда настраивать тесты?
Чем более согласованным становится приложение, тем выше риск пропустить аномалию.
Лучшее время для реализации стратегии тестирования - на этапе разработки приложения, прежде чем вы начнете писать код.
После того, как эта стратегия будет разработана и подтверждена всей командой, тесты можно записать как развитие прогрессирует.
Это также может быть хорошее время для обучения команд использованию тестов. Что будет намного сложнее организовать после запуска проекта.
Но если ваш проект уже существует или уже запущен, вполне возможно наверстать упущенное и потом настроить тесты. Имейте в виду, что это займет немного больше времени.
Определите методологию
Как интегрировать реализацию тестов в приложение? Существует несколько методик организации написания тестов:
- TDD (Разработка через тестирование): Разработка через тестирование - это метод разработки программного обеспечения, который поддерживает модульное тестирование перед написанием исходного кода проекта.
- BDD (Behavior Driven Development): рекомендует объединить в одном документе требования (пользовательские истории), выраженные в соответствии с формализмом «роль-функция-выгода», и сценарии или примеры, выраженные в соответствии с Структура «дано-когда-тогда». Очень хорошо сочетается с TDD.
- ATDD (Acceptance Test-Driven Development): Управление с помощью бизнес-тестов. Тесты создаются и автоматизируются до разработки.
- RJD (Rush Job Development): реализация тестов после написания исходного кода, чтобы гарантировать минимальную регрессию.
По этому поводу есть что сказать, если вам нужна дополнительная информация, вы можете обратиться к этой более подробной статье: Обзор методов TDD, BDD и ATDD.
Выберите команду для работы над этим проектом
Звучит просто, но, тем не менее, это решающий момент для успешной реализации стратегии тестирования в проекте.
Чтобы объяснить, почему это важно, вот несколько предложений, которые я уже слышал о своих различных профессиональных проектах:
«Оставьте рассчитанный бюджет на тесты до конца на тот случай, если у нас закончится бюджет» Менеджер X
«Мы проведем тесты в конце, если не опоздаем с графиком» Менеджер Y
«В любом случае тестировать интерфейсное приложение бесполезно» Разработчик X
«Я ничего не знаю о тестировании, посмотрю по мере разработки» Разработчик Y
Как вы думаете, смогли ли эти проекты создать хорошую стратегию тестирования? Очевидно нет.
Настройка тестов в проекте требует затрат и требует времени!
Первое лицо, которое убедит в команде: менеджер!
Он должен подтвердить факт количественной оценки тестов в предложении, сделанном клиенту, или то, что сроки доставки увеличены по сравнению с проектом без тесты.
Как только менеджер соглашается, не отпускайте!
Это, наверное, самая сложная часть, но если вы сдадитесь на ранней стадии, а тесты не будут проведены ... они никогда не будут установлены вверх!
Второе лицо, которое должно убедить: разработчики.
Следует признать, что реализация тестов не является предпочтительной частью разработчиков.
Но мы должны заставить их понять интерес иметь тесты в своем приложении:
- Меньше регрессий, следовательно, меньше аномалий, которые нужно исправить впоследствии
- Меньше ручных тестов для выполнения
- Меньше отзывов от «вредителей»: руководитель проекта / менеджер / клиент / коммерческий директор / и т. Д.
- Больше автоматизации
- Новые навыки для приобретения
Часто возникает вопрос: обязательно ли брать разработчиков, которые уже прошли тест?
Да и Нет: лично я рекомендую 1 человека с опытом работы в этой области в команде, чтобы быстрее повышать навыки других.
Например, младший разработчик, работающий над написанием модульных тестов, будет медленнее продвигаться по этой части в начале проекта, но будет прогрессировать очень быстро, если он хорошо обучен или хорошо сопровождается.
Главное, чтобы разработчик не устойчив к испытаниям, которые неизбежно приведут вашу стратегию к провалу.
Третье лицо (необязательно): менеджер по тестированию или квалификационная группа
В зависимости от проекта за написание тестов может отвечать специальная подгруппа. Это очень хорошо применимо к методологиям BDD и ATDD для написания функциональных тестов.
Что касается технических тестов, я рекомендую, чтобы этот человек был интегрирован в команду разработчиков, что позволяет, например, настроить тестирование / разработку однорангового программирования.
Технический тест всегда должен проводиться как можно ближе к группе разработчиков, которая знает исходный код и функции, которые нужно тестировать.
4-е лицо: заказчик!
И да, вам, как клиенту, придется платить больше за правильно протестированное приложение.
Но хорошо протестированное приложение является гарантией качества и безопасности и значительно сэкономит время в конце проекта.
Всегда приятнее и обнадеживающе доставить проверенное и проверенное приложение, чем приложение, в котором в течение 1-й недели после принятия было зарегистрировано 1234300 аномалий.
Резюме
Прежде чем настраивать тесты на проекте, вы должны задать себе правильные вопросы:
- Какую стратегию тестирования я хочу реализовать?
- Когда мне поставить на место?
- По какой методике?
- Какая команда для этого проекта?
Если у вас есть ответ на эти 4 вопроса, самое сложное сделано!
Все, что вам нужно сделать, это выбрать инструменты, которые позволят вам реализовать вашу стратегию.
Теперь, когда вы поняли, какие тесты нужно настроить для приложения javascript, и что вы определили свою стратегию, найдите инструменты для настройки во второй части этой статьи:
Как« правильно протестировать приложение javascript? С какими инструментами? (Часть 2)"
Понравилась статья? Поддержите меня 42 аплодисментами и подписывайтесь на меня в Twitter, чтобы получать больше информации в Интернете и на мобильных устройствах.
Если вы хотите внести свой вклад в эту статью и помочь мне ее перевести, свяжитесь со мной 😉
