Разработка через тестирование: как писать модульные тесты

Как начинающий программист, вы часто слышите советы протестировать свой код. Это хороший совет — давайте посмотрим, как вы можете начать это делать!

Что такое модульные тесты?

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

Это программа, которая проверяет вашу программу.

Обычно в проектах JavaScript вы будете использовать некоторую библиотеку тестирования, например:

• Шутка,

• Жасмин или

• Chai

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

Как вам помогают модульные тесты

Есть четыре способа написания тестов, которые облегчат вам жизнь программиста:

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

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

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

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

Соберите строительные леса

Прежде чем тестировать функциональность, убедитесь, что вы можете протестировать что угодно. Установите библиотеку тестирования и настройте сценарий тестирования. Как только у вас что-то заработает, вы можете приступить к настройке скаффолдинга для некоторых ваших тестов. Вам нужно определиться с соглашением об именах. Например, если ваш код называется my-project/plane-ticket.js, ваш тестовый код может находиться в my-project/plane-ticket.spec.js.

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

• если объект является объектом, или

• если функция есть функция

Таким образом, вы докажете, что можете тестировать вещи.

Настроить мокирование

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

Сохраняйте структуру

Как видите, в каждом тесте происходит много всего. Можно выделить три основных этапа:

1. Настройка моков

1. Запуск кода, который вы хотите проверить

1. Проверьте ожидания

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

Разработка через тестирование

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

Если вы будете следовать этой практике, вы никогда не пропустите ни одного теста на логику. Нет никакого соблазна пропустить написание тестов — распространенная проблема, когда вы оставляете написание тестов в конце спринта.

Контррекомендация

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

Отсутствующие тесты

Если вам не повезло, вы можете работать с унаследованным кодом без тестов и любых других мер, связанных с качеством — что-то вроде [я описываю здесь] (https://how-to.dev/how-to-manage-fragile-legacy- код). В таком случае все же лучше поздно, чем никогда; вы можете начать писать тесты, пока работаете над кодовой базой. Таким образом, вы улучшите ситуацию в будущем и, возможно, обнаружите неприятные ошибки, скрытые в некоторых редких крайних случаях.

А ты?

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