Почему мы тестируем

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

Я выпускник Hack Reactor и до недавнего времени боялся тестирования. Hack Reactor сильно подчеркивает важность тестирования, и я вышел из трех месяцев интенсивного обучения написанию Javascript с твердой верой в риторику разработки через тестирование (TDD): все хорошие разработчики тестируют свой код. К сожалению, на многих учебных курсах (включая Hack Reactor) просто нет времени на то, чтобы научить студентов как проводить тестирование. И у меня не было времени на то, чтобы это выучить. Я был слишком занят изучением основ React и Node, чтобы придумывать новые библиотеки для их тестирования. Когда подошло время собеседований, я мог бы назвать все причины, по которым вы должны протестировать свой код. Я мог бы даже перечислить различные способы сделать это. Но я понятия не имел, как реализовать любой из них.

К тому времени мои навыки разработчика достигли той точки, когда я писал большую часть своего внешнего кода на React / Redux. Но хотя я был в восторге от моей новой способности писать сложный код, меня парализовала мысль о попытке написать тесты для сложного кода. Я так долго откладывал обучение тестированию, что казалось почти невозможным.

Фон

Возможно, когда вы слышите, как люди говорят о том, как важно тестировать код, вы думаете: «Ага, ага». Если вы потратили хотя бы час на обучение программированию, вы столкнулись с ошибкой. Если вы потратили два часа на программирование, значит, вы написали исправление, которое привело к возникновению новой ошибки! (Это настолько распространенное явление, что существует особый тип тестирования, предназначенный для его предотвращения: регрессионное тестирование.) К сожалению, как бы важно ни было тестирование, не всегда очевидно, как его проводить.

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

У этого процесса много преимуществ. Если выяснится, что никто не хочет использовать продукт, потратите все усилия (и деньги) на его усовершенствование (и тестирование) напрасно. Но если люди действительно захотят его использовать, инженеры могут продолжить разработку MVP, добавляя новые функции и делая продукт более надежным и масштабируемым. Итерация также означает, что компании могут быстрее адаптироваться к отзывам потребителей, конкурентам и рынку. Итак, вместо того, чтобы заставлять инженеров создавать законченный продукт, а затем заставлять инженеров по обеспечению качества тестировать весь продукт, а затем развертывать полный продукт в конце месяца работы ... теперь мы строим MVP, постоянно развертывая новые функции и исправляя ошибки. И как часть этого процесса инженеры пишут тесты для своего кода по мере его написания или исправления ошибок в нем.

Автоматическое тестирование

Но как они это проверяют? Было бы утомительно и деморализовать вручную проверять функциональность всего приложения каждый раз, когда вы вносите незначительные изменения в кодовую базу. Кроме того, ваше приложение не должно быть очень большим, прежде чем вы начнете с трудом вспоминать все, что нужно проверить! А что, если кто-то еще захочет изменить написанный вами код, но не знает о каком-то причудливом крайнем случае, для которого он был написан? Они могут исключить код, необходимый для предотвращения взлома приложения в этой нечастой, но, возможно, критически важной ситуации.

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

Как не стать таким же, как я!

Начни тестирование прямо сейчас.

Первые несколько статей этой серии будут нацелены на людей, которые немного изучили Javascript (например, методы и функции массивов), но не обязательно знают более сложные темы (например, как создавать объекты или использовать библиотеки). Если вы можете написать базовый код, вы можете написать базовые тесты для этого кода. И это отличный момент, с которого можно начать изучать тестирование, так как по мере продвижения вперед у вас будет понимание концепции и вы сможете подойти к ней с меньшим страхом. Таким образом, вы сможете расширить свое понимание тестирования по мере развития остальных своих знаний.

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

Часть 2A рассматривает, как реализовать модульные тесты с использованием console.assert().

Часть 2B рассматривает алгоритмы A / B-тестирования с использованием console.time() и console.timeEnd().