Тестировать сложно, но знать, что и когда тестировать, на самом деле еще сложнее. Позвольте мне рассказать вам о 3 типах тестов, которые могут помочь вам защитить ваш проект.

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

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

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

Мы можем разделить идеальные тесты на 3 типа:

  • Тест, который поможет вам построить
  • Тест, который поможет вам отладить
  • Тест, который поможет вам хорошо спать по ночам

Тест, который поможет вам построить

Цель тестирования программного обеспечения — убедиться, что наш код работает!

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

Например, у нас есть массив чисел:

const arr = [1,2,3,4,5]

И мы хотим написать простую функцию, которая добавляет +1 к каждому числу массива без использования каких-либо встроенных функций массива, таких как map или reduce.

Если вы начнете с простого цикла for от 0 до 5, выполните итерацию по массиву и добавите 1 к каждому значению, мы можем создать граничный тест, в котором вместо передачи массива из 5 значений мы будем передавать массив из 6 значений или пустой массив.

Наши тесты потерпят неудачу, и мы улучшим наш дизайн, изменив цикл for, включив в него длину массива.

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

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

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

Вот что такое разработка через тестирование (TDD).

Тест, который поможет вам отладить

Это когда-нибудь случалось с вами?

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

Он был введен недавно, но вы не знаете, как и, что более важно, когда.

В октябре 2022 года Git представил очень удобную команду под названием git bisect.

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

Но прежде чем запускать процесс git bisect, вам нужен тест, чтобы определить, присутствует ошибка или нет.

Допустим, у вас есть ошибка в процессе входа в систему. Вы бы написали e2e, который имитирует поток для вас.

Подготовив тест, вот как его использовать для поиска коммита, вызвавшего ошибку:

  1. Запустите процесс bisect, запустив git bisect start.
  2. Определите коммит, который известен как «хороший», и запустите git bisect good <commit>.
  3. Найдите заведомо «плохой» коммит и запустите git bisect bad <commit>.
  4. Затем Git проверит фиксацию, которая находится на полпути между хорошей и плохой фиксацией.
  5. Выполните тест, чтобы определить, является ли текущая фиксация хорошей или плохой. Если все в порядке, запустите git bisect good. Если это плохо, запустите git bisect bad.
  6. Повторяйте этот процесс, пока git bisect не найдет фиксацию, вызвавшую ошибку.
  7. Когда git bisect найдет коммит, он выведет хэш коммита и сообщение.
  8. Запустите git bisect reset, чтобы остановить процесс разделения пополам и вернуться к фиксации HEAD.

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

Тест, который поможет вам хорошо спать по ночам

Инженеры любят сложность.

Например, создание программного обеспечения, которое делает то, что никто или никакое другое программное обеспечение не делало раньше.

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

На самом деле я написал статью о 5 методах тестирования, которые вы должны иметь в своем пайплайне CI/CD, но правда в том, что очень простой синтетический тест принесет вам больше пользы, чем все эти вместе взятые.

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

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

Сторонние инструменты мониторинга и наблюдения, такие как платформы DataDog, Sentry или Testing as Service, позволяют вам создавать такие тесты, которые выполняются в вашем приложении каждую минуту и ​​предупреждают вас, если что-то пойдет не так.

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

Тестирование программного обеспечения полезно не только для проверки правильности вашего программного обеспечения.

Воспользовавшись всеми преимуществами тестов, вы можете использовать их для улучшения написания кода, используя методы TDD, такие как Red-Green-Refactor или Triangulation.

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

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

Разве это не звучит просто идеально?

Если вам понравилась эта статья, не забудьте подписаться на меня в Medium или в Twitter, чтобы общаться и обмениваться идеями.

В основном я пишу о тестировании, фронтенд-инжиниринге или производительности. Здесь вы также можете посмотреть мой канал на YouTube.

Вот пара статей, которые я также написал: