В статье, опубликованной на прошлой неделе, я рассказал о нескольких способах улучшения качества вашего кода. Некоторых читателей больше интересуют юнит-тесты, и сегодня мы поговорим о том, нужно ли писать юнит-тесты? С командой тестировщиков писать модульные тесты — пустая трата времени?
1. Для чего именно используются модульные тесты?
На случай, если некоторые читатели не понимают модульное тестирование, прежде чем обсуждать эту тему, позвольте мне кратко объяснить, что такое модульное тестирование?
Модульное тестирование, как следует из названия, проверяет небольшой «модуль», который обычно является классом или методом, а не модулем или системой.
Модульное тестирование обычно выполняется инженерами-разработчиками и представляет собой тест на уровне кода, используемый для проверки правильности кода, написанного «я».
Модульное тестирование не равнозначно разработке через тестирование. Разработка через тестирование — это идея разработки, полная идеалов, но непрактичная. Эффект модульного тестирования эквивалентен разработке через тестирование, но его проще реализовать.
Модульное тестирование не зависит от каких-либо неуправляемых компонентов.Если код зависит от других неуправляемых компонентов, таких как сложные внешние системы, сложные модули или классы, вам нужно использовать mocking, чтобы сделать эти неуправляемые части управляемыми.
На самом деле написание юнит-тестов само по себе не требует передовых технологий. Работает корректно в любой ожидаемой или неожиданной ситуации.
2. Каковы преимущества написания модульных тестов?
По моему личному опыту, когда мы пишем программы, мы обычно ориентируемся на то, соответствует ли работа программы в нормальных условиях ожиданиям, и часто не учитываем в полной мере работу программы в нештатных условиях.
После того, как вы написали функциональный код, как вы можете убедиться, что ваш код работает правильно? В случае различных исключений (исключения данных, исключения ввода, исключения вызовов и т. д.) результаты работы программы соответствуют вашим заранее разработанным ожиданиям, а как насчет возврата соответствующей ошибки?
Здесь пригодится модульное тестирование. Из моего личного опыта написания юнит-тестов, при написании юнит-тестов, почти каждый раз, когда я нахожу много мест, не рассмотренных всесторонне, я нахожу множество «багов». Хорошо продуманные модульные тесты очень полезны для исправления всех видов низкоуровневых ошибок в коде. Поэтому я всегда считал, что самый эффективный способ улучшить качество кода — написать модульные тесты. В Google есть много проектов, в которых команда тестирования вообще не участвует. Корректность кода полностью гарантируется командой разработчиков, а онлайн-ошибок очень мало.
Более того, процесс написания модульных тестов сам по себе является процессом самопроверки кода. В этом процессе вы можете обнаружить некоторые проблемы проектирования, такие как непроверяемый дизайн кода, плохая читабельность кода и так далее.
Написание модульных тестов также повышает вашу уверенность в своем коде. Когда вы пишете полные модульные тесты и ваш код проходит все тестовые случаи, вы будете более уверены в написанном вами коде. Это чувство контроля — это хорошо :) Если вы хорошо написали модульные тесты, это должно находить отклик у меня в этот момент.
В дополнение к этому модульное тестирование также очень помогает при рефакторинге кода. Когда вы обнаружите, что какой-то класс или функция реализованы плохо, вы хотите провести его рефакторинг, но боитесь, что не рассмотрите его всесторонне, и сделаете ошибки после его изменения.
Другое дело, если у вас есть модульные тесты. После рефакторинга кода вы запускаете исходные модульные тесты. Если все модульные тесты пройдены, в основном гарантируется, что ваш рефакторинг не нарушил правильность. Однако предпосылкой этого является то, что модульные тесты, написанные ранее, имеют хорошее качество и широкий охват.
3. Почему мало компаний пишут модульные тесты?
Насколько мне известно, отечественные интернет-компании, в том числе и BAT, редко пишут юнит-тесты всерьёз, особенно некоторые проектные команды, разрабатывающие бизнес-системы. Я лично думаю, что это как-то связано с технологической культурой и моделью исследований и разработок всей компании.
Техническая культура многих компаний не имеет представления о «качестве кода» сверху донизу. Пока написанный код можно скомпилировать и передать, и он работает, как ожидается, при нормальных обстоятельствах, отправьте его напрямую, а затем бросьте его команде тестирования для безжалостного тестирования. После того, как команда тестирования обнаружит проблему, она будет передана команде разработчиков для доработки. Проблемы, которые невозможно обнаружить, остаются на линии и решаются после их возникновения.
Кроме того, многие из наших компаний 996, 995, ориентированы на бизнес, и график работы плотный. У инженеров по исследованиям и разработкам просто нет времени и сил на написание модульных тестов. Потому что в целом объем кода для юнит-тестирования зачастую больше, чем объем тестируемого кода, примерно в 1-2 раза.
При такой модели разработки и технической культуре команды часто считают, что модульное тестирование не нужно и является пустой тратой времени. Однако, если наша команда разработчиков хорошо пишет модульные тесты, хорошо проводит проверку кода и уделяет внимание качеству кода, это на самом деле долгосрочная инвестиция в проект.
Есть хорошая поговорка: «Медленно значит быстро». Хотя написание модульных тестов и обзоров кода могут временно повлиять на текущий прогресс НИОКР, в долгосрочной перспективе проекты с высоким качеством кода будут иметь гораздо более высокую общую эффективность НИОКР.
Наконец
Сегодня я в основном говорю с вами о модульном тестировании и рассказываю о преимуществах модульного тестирования. Вы также можете оставить сообщение и сказать мне, что еще вы хотели бы услышать о модульном тестировании? Или расскажите о своих взглядах на юнит-тестирование, писали ли вы юнит-тесты в своем проекте? Как вы думаете, стоит ли тратить время на написание?
Автор Ван Чжэн, бывший инженер Google, автор книг «Красота структур данных и алгоритмов» и «Красота шаблонов проектирования», на которые подписано 150 000 человек. Общедоступная учетная запись WeChat: Сяо Чжэнгэ, подпишитесь на общедоступную учетную запись WeChat, чтобы ответить на PDF-файл, и получите более 100 страниц изучения алгоритмов и обмена опытом интервью с инженерами Google.