По мере роста экосистемы JavaScript растет и потребность в качественном тестировании программного обеспечения. Беседы на This.JavaScript: State of Testing ставят тестирование в центр внимания.

Это мероприятие было организовано совместно Трейси Ли (@ladyleet), This Dot Labs и Гилом Тайаром (@giltayar), старшим архитектором Applitools.

Хорошо осведомленная группа участников представила обновленную информацию о состоянии внешнего тестирования своими глазами, что вызвало оживленную дискуссию. Разнообразные темы касались передовых практик, эволюции инструментов и будущего тестирования в 2019 году.

Разговоры варьировались от недостатков деталей тестирования реализации до оценки причин, по которым все больше разработчиков не проводят тестирование регулярно, и сравнения лучших вариантов использования интегрированных и изолированных тестов.

Среди избранных гостей и темы:

  • Кент С. Доддс (Опасности, связанные с подробностями тестирования реализации)
  • Глеб Бахмутов (Покрытие кода: бесполезно ли оно в тестах e2e?)
  • Гил Тайар (Быстрое кроссбраузерное визуальное тестирование с помощью Applitools)
  • Ротем Мизрахи-Мейдан (Устранение снижения производительности)
  • Джеймс Эванс (State of Selenium)
  • Кевин Лэмпинг (Почему разработчиков не хватает тестирования?)
  • Шай Резник (Изолированное и интегрированное тестирование)

Вот некоторые из основных выводов:

Опасности подробностей тестирования реализации

с Кентом К. Доддсом (@kentcdodds), преподавателем веб-разработки

Кент С. Доддс рассказал об опасностях использования деталей реализации при тестировании и о риске неточности, если вы их не избегаете.

Каковы детали реализации?

«Вы можете думать о деталях реализации как о чем-то, что не имеет отношения к пользователю этого компонента, библиотеки или приложения». - Кент С. Доддс

Другими словами, пользователи вашего кода обычно не используют, не видят и даже не знают о деталях реализации.

Когда дело доходит до тестирования, детали реализации - дело рискованное. Но почему?

· Детали реализации тестирования могут нарушить ваш тест при рефакторинге кода приложения. Это приводит к ложноотрицательным результатам.

· С другой стороны, тест не может потерпеть неудачу, если вы нарушите код приложения. Это приводит к ложным срабатываниям.

Но: Есть альтернативы.

Чтобы избежать деталей реализации при тестировании, начните с вопроса: «Какая часть вашей непроверенной кодовой базы будет действительно плохой, если она сломается?»

Затем попробуйте сузить этот код до единицы или нескольких единиц. Подумайте, кто его пользователи, и составьте список способов, которыми пользователи могут вручную протестировать его, чтобы убедиться, что он не сломан. Наконец, превратите этот список в автоматический тест.

Дополнительные сведения о том, как избежать деталей реализации при тестировании и быть максимально точными, см. В сообщении блога Кента по этой теме.

Покрытие кода: бесполезно ли оно в тестах e2e?

с Глебом Бахмутовым (@bahmutov), ​​вице-президентом по инжинирингу Cypress

Глеб Бахмутов отвечает на вопрос: как мы узнаем, что закончили тесты?

Покрытие кода используется часто, но это сложно. Это полезно только для модульных тестов. Покрытие кода не учитывает все типы данных и возможные крайние случаи, что делает его не идеальным.

Покрытие данных и покрытие кода бесполезны для сквозного тестирования. Представьте, что вы пытаетесь проверить каждую часть автомобиля, просто проезжая на нем. Было бы не очень эффективно, правда? Точно так же вы не можете охватить все части вашего кода только через его пользовательский интерфейс.

Ответом на эту проблему является покрытие элементов, которое охватывает весь пользовательский интерфейс приложения.

Перейдите в его сообщение в блоге для получения дополнительной информации и, надеюсь, более точного тестирования.

Быстрое кроссбраузерное визуальное тестирование с помощью Applitools

с Гилом Тайаром (@giltayar), евангелистом и архитектором Applitools

Гил Тайар из Applitools рассказал нам о достоинствах быстрого кросс-браузерного визуального тестирования.

Существует много типов автоматизированного тестирования, но только некоторые из них имеют визуальные компоненты, включая тесты компонентов, функциональности, e2e и производственного мониторинга. И до недавнего времени реальных инструментов для визуального тестирования не существовало. Но, к счастью, это меняется.

В подходе к тестированию Applitools разработчики делают скриншоты того, что они хотят визуально протестировать, и сравнивают их с базовыми показателями. Если нет отличий, у нас все хорошо! Если есть, то это могло быть либо хорошей разницей…, либо ошибкой.

Для любопытных потенциальных пользователей Гил также поделился несколькими ключевыми особенностями Applitools Cypress SDK:

· Это быстрый, хорошо продуманный фреймворк e2e.

· Он позволяет проводить как кросс-браузерное, так и кросс-ширину визуальное тестирование, потому что адаптивный дизайн так важен в сегодняшнем цифровом ландшафте.

· Applitools Cypress SDK использует моментальные снимки DOM и загружает их в визуальную сетку. Результат? Несколько тестов могут быть распараллелены и запущены как один тест одновременно.

· Он использует анализ первопричин или сравнение базовой модели DOM и фактической модели DOM, чтобы выяснить, что в CSS или DOM вызвало визуальную ошибку, для большей точности и эффективности.

Зайдите на Applitools.com и попробуйте сами!

Устранение снижения производительности

с Ротемом Мизрахи-Мейдан (@rotemmiz), Detox E2E в Wix

Ротем Мизрахи-Мейдан хочет устранить снижение производительности. С этой целью он поделился тем, что люди Detoxe2e в Wix делают для обеспечения долгосрочного успеха.

Цель CI - автоматизировать сложные и повторяющиеся задачи, которые мы выполняем. Как всегда, цель - более эффективное и точное тестирование.

Чтобы убедиться, что это так в долгосрочной перспективе, Rotem использует инструменты Detox. Эти инструменты работают внутри инструментированного процесса, отбирая и собирая метрики изнутри приложения. После этого записанные данные становятся легкодоступными и могут быть нанесены на графики и информационные панели для построения графиков тенденций с течением времени.

Эти инструменты могут служить моделью того, что мы можем сделать, чтобы гарантировать, что тестирование останется полезным и точным в будущем, а не только в данный момент.

Его ключевой вывод ?

«Вы не можете улучшить то, что не измеряете». -Ротем Мизрахи-Мейдан

Состояние селена

с Джеймсом Эвансом (@jimevansmusic), экспертом по Selenium и QA в Salesforce

Джеймс Эванс, QA в Salesforce, является экспертом по Selenium. Для тех, кто не знает, Selenium - это библиотека автоматизации браузера, которая в основном используется для тестирования пользовательского интерфейса. Он превосходит кросс-браузерное тестирование.

Чуть менее десяти лет назад Selenium представил API под названием WebDriver, который стал стандартным API автоматизации браузера для Selenium. WebDriver не зависит от языка; есть привязки для WebDriver для языков .NET, а также для Java, C #, Python, Ruby и, конечно же, JavaScript.

В 2019 году Selenium ожидает замечательных нововведений. Все реализации WebDriver в настоящее время в высокой степени поддерживают спецификацию (результаты тестирования доступны на wpt.fyi).

Уже началась работа по его выводу на новый уровень в 2019 году, включая двунаправленную связь между тестовым кодом и тестируемым приложением.

Как и большая часть тестовой экосистемы, Selenium ждет нового года! Мы очень рады видеть, что будет дальше.

Почему не хватает тестирования разработчиков?

с Кевином Лэмпингом (@klamping), интерфейсным инженером и тестировщиком

Данные показывают, что по крайней мере половина разработчиков в той или иной форме пишут тесты. Однако многие не довольны своим тестированием.

Но почему? Это инструменты? Не совсем так: опросы показывают, что разработчики со временем все больше довольны доступными инструментами тестирования.

Это документация? Не совсем так: большинство разработчиков не думают, что тестирование слишком сложно изучить или внедрить. Курсы намекают на важность тестирования и на то, что образование стало более доступным, чем когда-либо прежде.

Вместо этого многие разработчики говорят, что у них недостаточно времени или что они не знают, как начать писать автоматические тесты.

Цитируя Кента С. Доддса, Кевин считает, что проблема проста. У тестирования нет очевидной рентабельности инвестиций. Если преимущества не очевидны, то недостатки имеют приоритет.

Его решение: «Либо продавайте тестирование, либо перестаньте спрашивать разрешения и просто сделайте это». - Кевин Лэмпинг

Вам следует написать тест, потому что он упрощает обновление вашего кода. Ваш тест должен быть функциональным для вас, но также и для ваших клиентов.

Лучшее тестирование делает код лучше, а лучший код делает клиентов более счастливыми.

Изолированное и интегрированное тестирование

с Шаем Резник (@ Shai.Reznik), основателем Hirez.io, руководителем семинара TestAngular.com

Шай Резник выступает за изолированное тестирование.

Основными преимуществами любого тестирования являются уверенность и качество кода. Но «модульное» и «интеграционное» тестирование - это нагруженные термины. Вместо этого мы должны говорить об измерениях тестирования: например, о масштабах, границах и предмете.

Под «границами» мы имеем в виду интегрированные и изолированные тесты.

Интегрированные тесты включают в себя тестирование нескольких частей кода вместе, в то время как изолированные тесты тестируют только одну часть кода и имитируют ее зависимость.

Интегрированное тестирование эффективно проверяет возможность подключения и то, как разные части нашего кода работают вместе.

Однако у него также есть несколько проблем, например:

· Нечеткие границы

· Бег требует больше времени

· Более длительная испытательная установка

· Мульти покрытие

· Тесты чаще ломаются

· Сложнее отслеживать ошибки

· Трудно закрываемые крайние корпуса

· Более свободный дизайн кода

В конечном итоге это приводит к ложному ощущению охвата.

Между тем, изолированные тесты имеют несколько ключевых преимуществ:

· Четкие границы

· Быстрее

· Нет проблем с несколькими покрытиями

· Более быстрая и простая настройка

· Легче отслеживать ошибки

· Легче покрыть крайние случаи

В конечном итоге во многих случаях это приводит к лучшему дизайну кода.

Так как же выбрать между интегрированным и изолированным тестами?

Ответ зависит от вашего проекта. Для небольших приложений достаточно интегрированного тестирования. Но для приложений среднего или большего размера изолированное тестирование или их комбинация, вероятно, лучше всего.

Куда мы будем двигаться дальше?

Состояние тестирования подтвердило важность тестирования для разработчиков. Вопреки распространенному мнению, где некоторые могут подумать, что тестируют только QA-инженеры, многие разработчики проводят тестирование сами и хотят сделать это лучше.

Некоторые из наших ключевых выводов по интерфейсному тестированию в 2019 году:

  • Разработчики тестируют больше, чем многие думают, и они хотят иметь инструменты, позволяющие делать это более эффективно.
  • Покрытие элементов является более полным и часто более эффективным, чем покрытие только кода.
  • Изолированное тестирование может повысить точность и улучшить дизайн кода для средних и крупных приложений.
  • Когда дело доходит до инструментов, передовых методов и инноваций, существует широкий спектр и богатое разнообразие возможностей тестирования .

Если вы не заметили Состояние тестирования, вы можете посмотреть его на YouTube здесь.

Узнайте больше о наших предстоящих событиях This.JavaScript на https://www.thisdot.co/this-js.

Мы хотим выразить особую благодарность нашим соорганизаторам и спонсорам Applitools, лучшего способа реализовать любое визуальное тестирование в ваших приложениях.