Skip to main content

Напишите тесты. Не слишком много. В основном интеграция.

Я сделал этот пост в блоге в виде беседы, и ее вы можете посмотреть здесь:

ПРИМЕЧАНИЕ. Это кросспост-сообщение из моего информационного бюллетеня. Я публикую каждое электронное письмо через две недели после его отправки.Подпишитесь, чтобы получить больше контента прямо на ваш email! 💌

Недавно Гильермо Раух написал в Твиттер нечто примечательное. Давайте быстро погрузимся в то, что это значит.

 
Пишите тесты. Не слишком много. В основном интеграцию.

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

Пишите тесты.

Да, для большинства проектов вы должны писать автоматические тесты. Вы должны, если вы цените свое время в любом случае. Гораздо лучше поймать ошибку локально на тестах, чем получить звонок в 2 часа ночи и исправить это. Часто я нахожу, что сэкономлю время, когда прикладываю время для написания тестов. Это может быть или не займет больше времени, чтобы реализовать то, что я создаю, но я (и другие) почти наверняка сэкономит время на его поддержание.

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

Не слишком много.

Я слышал, что менеджеры и команды отвечали за 100% -ное покрытие кода для приложений. Это действительно плохая идея. Проблема в том, что вы получаете уменьшающуюся отдачу от своих тестов, так как охват значительно превышает 70% (я сделал это число ... без науки). Почему это? Ну, когда вы все время стремитесь на 100%, вы проводите время, проверяя вещи, которые действительно не нуждаются в проверке. Вещи, которые вообще не имеют никакой логики в них (так что любые ошибки могут быть обнаружены ESLint и Flow). Поддержание таких тестов на самом деле действительно замедляет вас и вашу команду.

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

Следует отметить, что почти все мои проекты с открытым исходным кодом имеют 100% -ный охват кода. Это связано с тем, что большинство моих проектов с открытым исходным кодом - это небольшие библиотеки и инструменты, которые многократно используются во многих ситуациях (разрыв может привести к серьезной проблеме во многих потребляющих проектах), и относительно легко получить 100% -ный охват кода так или иначе.

В основном интеграция.

Существуют различные виды тестирования (ознакомьтесь с моими 5-минутными разговорами об этом в Fluent Conf: «Что мы можем узнать о тестировании с колеса» ). У каждого из них есть компромиссы. Три наиболее распространенные формы тестирования, о которых мы говорим, когда мы говорим об автоматическом тестировании, это: Unit, Integration и End to End.

Вот слайд моей мастерской Frontend Masters: «Тестирование приложений JavaScript».

Испытательная пирамида

Эта тестовая пирамида - комбинация того, что я получил из блога Мартина Фаулера, и найденного в Google Testing .

Как указано здесь, пирамида показана снизу вверх: Unit, Integration, E2E. Когда вы двигаетесь вверх по пирамиде, тесты становятся медленнее, чтобы писать / запускать и более дорого (с точки зрения времени и ресурсов) запускать / поддерживать. Это означает, что вы должны тратить больше времени на модульные тесты из-за этих факторов.

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

Мое самое переработанное твит, связанное со временем, связано с основной проблемой с модульными тестами:

Все еще люблю этот. Модульные тестеры выглядят следующим образом: «Похоже, что он работает»
 
Человек в трех частях. Ноги бегут на месте. Торс делает отжимания. Головное чтение.

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

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


Как написать больше тестов интеграции

Линия между интеграционными и модульными тестами немного нечеткая. Независимо от того, я думаю, что самое большое, что вы можете сделать, чтобы написать больше тестов интеграции, - это просто перестать насмехаться над такими вещами . Когда вы издеваетесь над чем-то, вы в основном снимаете уверенность в интеграции между тем, что вы тестируете, и тем, что насмехается. Я понимаю, что иногда это не может помочь (хотя некоторые из них не согласятся). Вы не на самом деле хотите , чтобы отправить электронную почту или с кредитной карточки каждый тест, но большую часть времени вы можете избежать поругания и вы будете лучше для него.

Если вы делаете «Реакт», то это включает мелкий рендеринг.Я уже давно говорю, что я чувствую, что мелкий рендер - это тестирование деталей реализации. В течение 3 минут на этом (и другие советы для тестирования) проверьте этот 3-минутный подкаст.

Надеюсь, это полезно! Желаю вам всем удачи! 👍

Не пропустите:

  • blog.kentcdodds.com  - Я начал публикацию в своей собственной средней публикации. Обязательно следуй за мной!
  • hacktoberfest  - Зарегистрируйтесь с GitHub здесь, и если вы сделаете 4 запроса на тягу в октябре месяце, они отправят вам бесплатную рубашку. Рад прав !?
  • draggable - вероятно, одна из самых крутых демонстраций для проекта, который я когда-либо видел.
  • Демо-версия Funky Karts  - классная игра, созданная WebAssembly. Спасибо, что поделился Джей Фелпсом!