😇
На testengineer.ru мы не размещаем рекламу, но над сайтом регулярно работают несколько человек. Поддержите нас, подписавшись на телеграм-канал "Тестировщик от бога"!
ДомойОбучениеUnit-тестирование6 оправданий для того, чтобы не писать юнит-тесты

6 оправданий для того, чтобы не писать юнит-тесты

Автор

Дата

Категория

Почему мы не пишем юнит-тесты?

Я начал писать эту статью с целью рассказать про unit-тестирование и о философии вокруг unit-тестов.

Хотел рассказать об удовольствии, которое получаешь после того, как видишь, как ни один из пары сотен unit-тестов не упал. И об уверенности, что твои изменения ничего не поломают.

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

У нас нет подходящих инструментов!

Да, это оправдание могло классно сработать в 80е. Если вы используете Paskal — у вас действительно может не быть удобных инструментов для тестирования.

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

В современные IDE и редакторы кода встроены test runner-ы, есть куча библиотек, облегчающих тестирование и интеграцию unit-тестов в CI/CD pipeline.

У нас нет времени, чтобы писать тесты!

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

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

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

код, в котором есть юнит-тесты vs код в котором нет юнит-тестов

Посмотрите на график выше. Оранжевая линия показывает зависимость разработки фич от времени для проекта без unit-тестов, синяя — для проекта с тестами.

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

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

Писать юнит-тесты тяжело!

Это абсолютная правда. Писать юнит-тесты тяжело. Хорошие юнит-тесты еще тяжелее. Не писать юнит-тесты — невыносимо (или вы предпочли бы вручную тестировать функциональность, написанную вашим предшественником лет 5 назад???)

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

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

Если вы работаете в компании, попросите лида написать несколько примеров хороших unit-тестов (или напишите сами, если знаете, как это сделать хорошо). Эти тесты могут использоваться как ориентиры для junior и middle инженеров.

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

Юнит-тесты бесполезные! Зря тратим время

Признаюсь, я никогда не думал о процессе написания юнитов, как о зря потраченном времени.

Я считаю, что тестирование своего кода вручную — вот зря потраченное время. Что получается на выходе ручного тестирования? Да, все работало, когда я тестировал, но как только я поменяю что-то в коде, никаких гарантий, что все будет работать как и раньше, нет. Придется повторно делать мануальный тест.

В случае с юнит-тестами, я могу запустить набор тестов в любое время и убедиться, что ничего из того, что работало раньше, не сломалось.

Более того, если я уволюсь и на мое место придет другой программист, он тоже сможет пользоваться моими тестами.

Ручное тестирование — это зря потраченное время (прим.ред. — для программиста) Мануальные тесты не оставляют после своего выполнения никаких ценных артефактов (часто они вообще никак не документируются). Юнит-тесты можно использовать на протяжение лет, чтобы проверять, что код работает так, как от него этого ожидают.

Мы тратим много времени на исправление упавших тестов!

Где-то раньше я уже написал, что писать юнит-тесты сложно.

Цель юнит-теста — проверить функциональность вашего приложения. Если вы не знаете (или не уверены), что делает ваше приложение, вы не сможете написать хороший тест.

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

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

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

Test Driven Design (TDD) подразумевает, что прежде, чем писать код, вы должны хотя бы подумать о том, как вы будете его тестировать. А в идеале написать тесты еще перед тем, как будете писать код.

По своему опыту могу сказать, что юнит-тесты всегда способствуют улучшению качества вашего кода.

Невозможно написать юнит-тесты для нашего кода! У нас супер-сложная система!

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

В идеале, вы должны покрывать код тестами в тот момент, когда его пишете. Если вы пытаетесь писать юниты для уже готового кода и делать это сложно — это сигнал того, что код плохой (плохо спроектирована система и т.п.)

Финальные размышления

Сколько unit-тестов писать

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

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

В чем преимущества?

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

Юнит-тесты однозначно сохранят вам много времени в долгосрочной перспективе и улучшат качество ваших программ.

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

Какой была ваша первая зарплата в QA и как вы искали первую работу?

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

5 КОММЕНТАРИИ

  1. Не знаю как в компании автора статьи, а у нас принято проверять мануально в любом случае (вне зависимости от того, пишутся юни тесты или нет)

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

  2. Отличная статья, жаль, не все понимают. Большинство разработчиков не любят писать юнит-тесты, не знаю, почему так повелось. Давно пользуюсь TDD-подходом и пишу юниты перед разработкой фич. При таком подходе, пока напишешь тесты, поймешь требования и продумаешь, как функциональность должна быть разработана.

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

ОСТАВЬТЕ ОТВЕТ

Пожалуйста, введите ваш комментарий!
пожалуйста, введите ваше имя здесь

$1100*
медианная зарплата в QA в ноябре

*по результатам опроса QA-инженеров в нашем телеграм-канале

Последние публикации

Последние комментарии