Серия Confident JS: Часть 3 - Проверьте, что повышает вашу уверенность

Серия Confident JS: Часть 3 - Проверьте, что повышает вашу уверенность

Будьте довольны своими тестами

Это третья часть серии:

• Часть 1 - Кодирование и декодирование полезной нагрузки для более разумных приложений
• Часть 2 - Типы, JSDocs и файлы объявлений
• [Вы здесь] Часть 3 - Проверьте, что повышает вашу уверенность в себе
• Часть 4 - Чуть функциональнее
• Часть 5 - Задача, Либо и Ящики
• Часть 6 - Fp-ts и io-ts, теперь пора серьезно

Писать или не писать тесты

Создание приложений - тяжелая работа, и иногда возникает ощущение, что мы имеем дело с чем-то вроде этого:

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

За свою карьеру в качестве Front-end разработчика я могу резюмировать два основных сценария сбоя, связанных с тестами.

Чрезмерное тестирование

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

У меня было ощущение, что мы должны все протестировать, я даже написал серию статей о том, как применять TDD во Front-end.

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

У нас было более 400 тестов… правда 😅

Я сделал следующие основные ошибки:

Неправильная абстракция

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

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

Неглубокий монтаж

Я могу провести рефакторинг реализации моего компонента, и мои тесты сломаются.

Я могу сломать свое приложение, и мои тесты проходят.

Подробная информация о тестировании

Отличный способ получить множество ложноотрицательных и ложных срабатываний 😉

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

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

Тестирование пренебрежения

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

• Потеря доверия клиентов из-за ошибок и проблем, которые могут произойти
• Вкладывать деньги в проблему, вкладывая средства в инфраструктуру или нанимая больше разработчиков, в большинстве случаев без реальной необходимости (привет утечки памяти)
• Тратить время на ненужное ручное тестирование каждый раз, когда что-то меняется
• Невыносимый технический долг, который может привести к «перезаписи приложений»
• Подали в суд из-за того, что жизненно важная часть вашей системы не сработала во время важной операции

Баланс между качеством и скоростью имеет решающее значение

Проверьте, что повышает вашу уверенность

Вещи начали щелкать, когда я впервые увидел Библиотеку тестирования, и я начал читать и смотреть Контент Кента С. Доддса.

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

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

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

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

Как?

В настоящее время мне нравится использовать Библиотеку тестирования для тестирования своих интерфейсных приложений, так как вы:

• Может писать тесты, которые больше напоминают использование вашего приложения
• У вас нет свободы делать то, что вы хотите, вы не можете делать вещи, которые могут привести к несоответствующим / несогласованным тестовым примерам (например, изменение программных реализаций, неглубокое монтирование компонентов)
• Можно использовать одну и ту же среду для нескольких фреймворков и сред
• Помогает вам улучшить доступность вашего приложения
• Это, естественно, помогает создавать более качественные тесты для ваших компонентов.

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

Краткий обзор проекта:

Это приложение для поиска пользователей Github, вы можете искать кого-нибудь по его имени пользователя, а затем мы выводим результат на экран.
❗️ Поскольку это сравнение с моей серией TDD, мы не обрабатывают состояние загрузки, сценарии ошибок и альтернативные пути специально для простоты, мы реализуем несколько вещей, которые уже видели в предыдущих частях, и в следующих частях я покажу, как поступать с этими сценариями мы здесь не освещаем

Вы можете найти старую часть здесь, в ветке main:

И если вы хотите сравнить, вы можете проверить новую реализацию здесь, в ветке testing-library:

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

В старой версии у нас около 12 тестов, а в новой версии - только 1 тест, что дает нам достаточную уверенность в основной цели приложения.

Как такой тест «заменит» 12 предыдущей версии?

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

Несколько ключевых моментов по этому тесту:

• Это намного короче
• Тестирует работающее приложение для конкретного сценария.
• В этом случае мы не хотим определять строгий контракт на реализацию, мы просто хотим гарантировать, что ожидаемое поведение работает.
• Единственный уровень, который подвергается имитации, - это использование Mirage.js, выходящего за рамки приложения , это означает, что мы не имитируем какое-либо поведение приложения.
• Единственное, чего мы здесь не можем гарантировать, - это случаи, когда ответ API отличается от того, что мы определили в Mirage (но мы могли бы создать тест e2e для проверки этого), в любом случае у нас есть свои декодеры, чтобы гарантировать согласованность во время выполнения.
• Тест E2E будет очень похож на этот код

Тогда почему бы просто не создать тест E2E?

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

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

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

Мои усвоенные уроки

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

• Это нормально - не инвестировать в тесты сразу, но это должно быть осознанное решение с планом на будущее, когда это произойдет.
• Тестирование во внешнем интерфейсе может быть трудным, поэтому не беспокойтесь о том, чтобы сделать ошибки или не знать, как / что тестировать, опыт приходит со временем, просто продолжайте изучать и применять все, что вы узнали ... Забота о качестве - это первый шаг
• Пересмотрите свои тесты и реорганизуйте их, они также являются частью кодовой базы, которая может нуждаться в обслуживании.
• Получите уверенность, протестировав соответствующие части вашего приложения, прежде чем думать о рефакторинге
• Если ваша среда не поощряет культуру качества и вы не можете ее изменить, возможно, это неподходящая среда для вас.

Вывод

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

Здесь вы можете увидеть несколько курсов и книг по этой теме:

Спасибо, что прочитали эту статью. Следите за обновлениями следующих частей.

Вам нравится то, что вы видите.

Хлопайте, оставьте комментарий или поделитесь где-нибудь. Мы ценим Ваш отзыв.

Также читайте другие статьи в нашем блоге. Мы занимаемся многими интересными вещами:

• 404: У нас проблема
• Как мы создали автоматизированную цветовую палитру, которая нравится дизайнерам и разработчикам
• Зачем и как мы проводим E2E-тесты
• Компоненты VueJS
• Фигурные иллюстрации
• Библиотека компонентов VueJS: почему мы создали нашу библиотеку компонентов пользовательского интерфейса
• Тестирование vue-testing-библиотеки
• и многое другое 😊!

Ознакомьтесь с нашими вакансиями в нашей команде разработчиков!

Простите за длинный пост, вот кот в костюме кота.