Для чего нужны модульные тесты
Зачем нужны юнит-тесты
Многие разработчики говорят о юнит-тестах, но не всегда понятно, что они имеют в виду. Иногда неясно, чем они отличаются от других видов тестов, а порой совершенно непонятно их назначение.
Доказательство корректности кода
Автоматические тесты дают уверенность, что ваша программа работает как задумано. Такие тесты можно запускать многократно. Успешное выполнение тестов покажет разработчику, что его изменения не сломали ничего, что ломать не планировалось.
Провалившийся тест позволит обнаружить, что в коде сделаны изменения, которые меняют или ломают его поведение. Исследование ошибки, которую выдает провалившийся тест, и сравнение ожидаемого результата с полученным даст возможность понять, где возникла ошибка, будь она в коде или в требованиях.
Отличие от других видов тестов
Все вышесказанное справедливо для любых тестов. Там даже не упомянуты юнит-тесты как таковые. Итак, в чем же их отличие?
Ответ кроется в названии: «юнит» означает, что мы тестируем не всю систему в целом, а небольшие ее части. Мы проводим тестирование с высокой гранулярностью.
Это основное отличие юнит-тестов от системных, когда тестированию подвергается вся система или подсистема, и от интеграционных, которые проверяют взаимодействие между модулями.
Основное преимущество независимого тестирования маленького участка кода состоит в том, что если тест провалится, ошибку будет легко обнаружить и исправить.
И все-таки, что такое юнит?
Часто встречается мнение, что юнит — это класс. Однако это не всегда верно. Например, в C++, где классы не обязательны.
«Юнит» можно определить как маленький, связный участок кода. Это вполне согласуется с основным принципом разработки и часто юнит — это некий класс. Но это также может быть набор функций или несколько маленьких классов, если весь функционал невозможно разместить в одном.
Юнит — это маленький самодостаточный участок кода, реализующий определенное поведение, который часто (но не всегда) является классом.
Это значит, что если вы жестко запрограммируете зависимости от других классов в тестируемый, ошибку, которая вызвала падение теста, будет сложно локализовать, и высокая гранулярность, которая необходима для юнит-тестов, будет потеряна.
Отсутствие сцепления необходимо для написания юнит-тестов.
Другие применения юнит-тестов
Кроме доказательства корректности, у юнит-тестов есть еще несколько применений.
Тесты как документация
Юнит-тесты могут служить в качестве документации к коду. Грамотный набор тестов, который покрывает возможные способы использования, ограничения и потенциальные ошибки, ничуть не хуже специально написанных примеров, и, кроме того, его можно скомпилировать и убедиться в корректности реализации.
Я думаю, что если тесты легко использовать (а их должно быть легко использовать), то другой документации (к примеру, комментариев doxygen) не требуется.
Тем не менее, в этом обсуждении после поста про комментарии видно, что не все разделяют мое мнение на этот счет.
Разработка через тестирование
При разработке через тестирование (test-driven development, TDD) вы сначала пишете тесты, которые проверяют поведение вашего кода. При запуске они, конечно, провалятся (или даже не скомпилируются), поэтому ваша задача — написать код, который проходит эти тесты.
Основа философии разработки через тестирование — вы пишете только тот код, который нужен для прохождения тестов, ничего лишнего. Когда все тесты проходят, код нужно отрефакторить и почистить, а затем приступить к следующему участку.
Об этой технике разработки можно много дискутировать, но ее неоспоримое преимущество в том, что TDD не бывает без тестов, а значит она предостерегает нас от написания жестко сцепленного кода.
И, поскольку TDD предполагает, что нет участков кода, не покрытых тестами, все поведение написанного кода будет документировано.
Возможность лучше разобраться в коде
Когда вы разбираетесь в плохо документированном сложном старом коде, попробуйте написать для него тесты. Это может быть непросто, но достаточно полезно, так как:
Модульное тестирование в современных командах
Для кого эта статья?
Для каких команд это подойдёт?
Я хотела бы показать вам процесс внедрения модульного тестирования для 2-х типов команд. В командах, которые работают по гибкой методологии и в командах, которые выбрали для себя каскадный стиль работы.
Ниже на диаграмме показано схематическое устройство команд по ролям:
Из этой схемы можно заключить то, что проджект менеджер, получая задачи от держателя продукта, согласовывает их со всеми участниками процесса и по результатам включает (или нет) их в спринт.
Чем модульное тестирование отличается от обычного?
Теперь хотелось бы рассказать что же такое модульное тестирование и как это реализовано в нашем случае:
Начну с того, что специалистами модульного тестирования являются эксперты в своих областях (под этим чаще всего понимается конкретная система). Они обладают широчайшим бэк граундом и необходимыми техническими навыками. Каждая система требует своих знаний, где-то это экспертные знания Pl/SQL, где-то конкретных языков разработки, а где-то только многолетний опыт работы с конкретной системой. Мы не затрагиваем front-end системы. Мы стоим на страже систем middle и back уровней.
Наверное ни для кого не секрет, что разработка/доработка любой фичи включает в себя изменения в системах на различных уровнях. Каждый модульный тестировщик проверяет новый функционал только в рамках своей системы. Тестируется код, соответствие контрактов без применения интерфейса. Выборка тестовых данных также происходит не вслепую, а на основе принципа минимального набора данных, покрывающего максимальное количество вариации выходных параметров. Для нас главное функциональная и техническая правильность написанного кода.
Первое отличие модульного тестирования от других видов заключается в том, что мы смотрим в код и ориентируемся на неизменность зафиксированных контактов/выходных параметров. Если они зафиксированы и не нарушаются, то в процессе интеграции систем фича включается без проблем.
И второе — это существенное снижение времени на тестирование доработки за счет экспертизы. Интеграционное тестирование смотрит фичу целиком, мы же рассматриваем ее по частям. Какие задачи решает модульное тестирование? Исходя из всего вышесказанного можно подвести черту и ответить на вопрос: какие же задачи решает модульное тестирование?
Польза внедрения модульного тестирования
После прочтения всего этого возникнет вопрос, а какие плюсы от внедрения модульного тестирования можно получить? Ранее я привела 2 схемы работы команд, и теперь опишу применительно к каждой из них:
Команда, работающая по аджайл методологии. Ниже на схеме приведено место модульного тестирования в команде такого типа:
В данном случае модульное тестирование подключается на поздней стадии разработки, когда происходит фактически уже «вылизывание» кода, а вся основная функциональность разработана. Модульному тестировщику НЕ НАДО начинать в процесс с начала, чтобы глянуть правильно ли выполнена разработка на бэк офисной системе или интеграционной шине.
В аджайл команде все участники процесса до начала разработки знают какие фичи они взяли в спринт и понимают как они должны работать с точки зрения конечного пользователя. В итоге мы приходим к тому, что время, которое необходимо затратить, прежде чем специалист приступит к тестированию, близко к нулю. Нам не нужно писать тест-кейсы (не спешите удивляться как же так, а как же передача знаний и тому подобное), мы сразу лезем в код и приступаем.
После окончания разработки мы получаем, что далее в тестирование задача идет уже проверенной и не содержащей критичных багов (как со стороны разработки, так и со стороны анализа). А что с некритичными? Такие баги встречаются, но крайне редко и обычно они завязаны на очень специфичные тестовые данные. Каждый такой кейс обрабатывается и заносится в вики команды. Но это еще не все плюшки, которые получаются на выходе!
При наличии в команде модульного тестирования автоматизатора (а он у нас есть!), на выходе мы также получаем автоматизированные модульные тесты! Это может быть набор тестов на каком либо выбранном тестовом фреймворке, либо набор скриптов, которые объединены в единый пак и вызываются по требованию/расписанию. Далее эти тесты включаются в некий регресс пак, который содержит в себе и автоматизированные модульные тесты и тесты отдела автоматизации (чуть позже мы рассмотрим, чем они отличаются) и прогоняется перед выводом задач спринта на бой. Что он нам дает думаю ясно и без моих пояснений.
Также допускается, подключение интеграционного тестированию параллельно с модульным тестированием. Пока команда тестирования через фронтовые системы дойдет до middle или back систем, тестирование будет выполнено уже более чем на 70-80%. Т.е. никаких простоев, связанных с необходимостью правки кода, у них не будет. Это что касается аджайл-команды.
Теперь посмотрим как обстоят дела в командах, которые работают по каскадному принципу. Схема с включенным модульным тестированием выглядит так:
Тут мы видим, что интеграционное тестирование начинается после окончания модульного. Это основное и принципиальное отличие от уже рассмотренного варианта. Пока задача не ушла с модульного тестирования, интеграционное тестирование не начинается. Готовятся тестовые сценарии, тестовые данные.
В остальном процесс не меняется, те же данные на выходе и те же плюшки, что и в agile командах.
Чуть выше я обещала поговорить о том, чем же отличаются автоматизированные модульные тесты, от автотестов команды автоматизации. Отличие очень простое и на поверхности. В 99% команда автоматизации автоматизирует не конкретную доработку, а процесс.
Рассмотрим на примере запроса информации по карте через интернет банк. Команда автоматизации пишет кейс на уровне фронта (логин/переход на вкладку/выбрали карту/нажали кнопку запросить баланс) Все мы знаем сколько по времени будет выполняться такой тест. А на выходе мы получим либо есть информация, либо ее нет. В очень редких случаях мы получим понимание в какой системе/каком функционале произошла ошибка.
Что с автоматизированными модульными тестами? Берем тот же пример. Тест написан на интеграционный уровень, которому на вход подается заполненный контракт (вытаскивается из фронтовой системы), далее происходит трансформация, вызов системы источника, обработка результатов и формирование ответа для системы приемника. В каждой точке стоит проверка. Осталось проверить, а точно ли все что надо вернула система источник? Далее вы знаете решение данной загадки. Тем самым мы получаем не один, а два теста, которые выполняются в несколько раз быстрее и дают исчерпывающие знания в случае ошибки. Не тратим время на анализ и разбор логов.
Как внедрить модульное тестирование?
Согласитесь, что простой целой команды на протяжении сколько-нибудь длительного времени это уже катастрофа? Поэтому основная польза от внедрения промежуточного этапа модульного тестирования в команду достаточно очевидна. Осталось только донести её до всех участников процесса и заинтересованных в конечном результате лиц.
Для начала нужно принять как данность, что не все понимают что вообще за зверь — модульное тестирование. Необходимо провести некоторую разъяснительною работу среди команды и доступно изложить всё то, что рассматривалось выше по поводу отличий такой команды от классических тестировщиков.
После подготовительной работы основная задача — добиться внедрения подхода с модульным тестированием хотя бы в тестовом режиме, выделив на это небольшую часть ресурсов.
После проведения нескольких показательных спринтов с новой формацией команды доказательствами эффективности такого подхода будут служить:
Заключение:
В итоге, по завершении всех вышеперечисленных операций по внедрению, модульное тестирование должно стать неотъемлемой частью процесса, которая позволит:
Все о Unit testing: методики, понятия, практика
Виды тестирования
Модульное тестирование (unit testing) — тесты, задача которых проверить каждый модуль системы по отдельности. Желательно, чтобы это были минимально делимые кусочки системы, например, модули.
Системное тестирование (system testing) — тест высокого уровня для проверки работы большего куска приложения или системы в целом.
Регрессионное тестирование (regression testing) — тестирование, которое используется для проверки того, не влияют ли новые фичи или исправленные баги на существующий функционал приложения и не появляются ли старые баги.
Функциональное тестирование (functional testing) — проверка соответствия части приложения требованиям, заявленным в спецификациях, юзерсторях и т. д.
Виды функционального тестирования:
Unit — модульные тесты, применяемые в различных слоях приложения, тестирующие наименьшую делимую логику приложения: например, класс, но чаще всего — метод. Эти тесты обычно стараются по максимуму изолировать от внешней логики, то есть создать иллюзию того, что остальная часть приложения работает в стандартном режиме.
Данных тестов всегда должно быть много (больше, чем остальных видов), так как они тестируют маленькие кусочки и весьма легковесные, не кушающие много ресурсов (под ресурсами я имею виду оперативную память и время).
Integration — интеграционное тестирование. Оно проверяет более крупные кусочки системы, то есть это либо объединение нескольких кусочков логики (несколько методов или классов), либо корректность работы с внешним компонентом. Этих тестов как правило меньше, чем Unit, так как они тяжеловеснее.
UI — тесты, которые проверяют работу пользовательского интерфейса. Они затрагивают логику на всех уровнях приложения, из-за чего их еще называют сквозными. Их как правило в разы меньше, так они наиболее тяжеловесны и должны проверять самые необходимые (используемые) пути.
На рисунке выше мы видим соотношение площадей разных частей треугольника: примерно такая же пропорция сохраняется в количестве этих тестов в реальной работе.
Сегодня подробно рассмотрим самые используемые тесты — юнит-тесты, так как уметь ими пользоваться на базовом уровне должны все уважающие себя Java-разработчики.
Что такое юнит-тесты и почему они так важны
Бывает, кодишь 10 минут, а дебажишь 2 часа. Чтобы такого не случилось, пилите юнит-тесты. Михаил Фесенко рассказал, как их правильно готовить.
Oli Scarff / Staff / GettyImages
Фесенко Михаил, можно просто Фес. Разработчик, раньше работал системным администратором, пишет на чём скажут, но пока писал на PHP, Go, Python, Bash. Сейчас работает в «Яндекс.Облаке», до этого работал во «ВКонтакте». Любит жену, кино и снимать видео =)
Юнит-тест (unit test), или модульный тест, — это программа, которая проверяет работу небольшой части кода. Разработчики регулярно обновляют сайты и приложения, добавляют фичи, рефакторят код и вносят правки, а затем проверяют, как всё работает.
Тестировать систему целиком после каждого обновления — довольно муторно и неэффективно. Поэтому обновлённые или исправленные части кода прогоняют через юнит-тесты.
Особенности юнит-тестов
На практике используют разные тесты — их разделяют по уровню абстракции с помощью пирамиды Майка Кона :
Чем выше тест в пирамиде, тем больше частей программы он затрагивает. Высокоуровневые тесты «ближе к бизнесу»: они проверяют бизнес-логику и пользовательские процессы. А те, что внизу пирамиды, помогают найти проблемы в отдельных частях кода. Например, какую-нибудь функцию, которая генерирует имя файла.
В отличие от них, юнит-тесты нужны в следующих случаях:
Некоторые программисты пишут только юнит-тесты, а на интеграционные или E2E-тесты жалеют времени. На самом деле нужно покрывать систему всеми видами тестов, чтобы знать, как взаимодействуют друг с другом разные части программы, какие промежуточные результаты они выдают. Но в то же время, если юнит-тесты показывают ошибку, её покажет и интеграционный, и E2E-тест.
Процесс юнит-тестирования
Для юнит-тестирования подключают тестовые фреймворки — они позволяют «мокать», то есть имитировать функции. В коде больших проектов много зависимостей: одна функция вызывает другую и влияет на разные части программы. Но, как правило, достаточно проверить функции «в вакууме», отдельно от остального кода. Для этого и нужен тестовый фреймворк — он моделирует условия, в которых функция А вызывает функцию Б изолированно от других функций.
Простой пример: у нас есть функция на Go, которая получает id бэкапа и возвращает имя бэкап-файла:
Протестируем её с помощью набора входных и выходных данных. Они должны учитывать все ситуации, поэтому не забываем про негативные кейсы — когда программа возвращает ошибку. Вот набор тестовых данных:
В первую очередь я прописал запрещённые данные (-1 и 0) и слишком большое значение (10200300). Когда пользователь их вводит, функция не должна возвращать результат. Вместо этого мы ждём сообщения об ошибке: BAD_ID или BACKUP_ID_TOO_BIG. Когда же функция получает валидный id, она выводит отформатированное имя файла, например Backup#000010.
А вот и код самого теста:
Порой код для тестирования даже больше основного — и это норма. Но иногда всё-таки стоит задуматься, на самом ли деле тест должен быть таким объёмным. Я бы посоветовал покрывать тестами только те фрагменты кода, которые вы планируете менять. Или сложные части, которые, скорее всего, придётся чинить или поддерживать.
Некоторые разработчики мокают всё подряд. Из-за этого тесты становятся хрупкими, а код — сложным и непонятным. На самом деле для юнит-тестирования достаточно лишь немного переписать код, а огромные функции лучше разбить на более мелкие.
В старой хорошей книге «Экстремальное программирование» есть классная мысль: сначала пишите тест, а только потом программу. Это клёвый подход, но не все могут так делать (а кто-то просто не хочет тратить время).
Как покрыть код юнит-тестами
Есть разработчики, которые не проводят модульное тестирование: «Ой, у нас большой проект, и переписать 1000 строк под тесты или замокать их — слишком запарно». На самом деле покрыть код тестами несложно. Вот несколько советов.
Написали код — напишите тест. Я видел много проектов, в которых юнит-тесты писали по принципу «новый код — новый тест». Думаю, это правильный подход, ведь, когда добавляешь в программу что-то новое, она часто ломается. К тому же, если писать тесты сразу, не придётся переворачивать весь код, когда он разрастётся.
Есть более жёсткий принцип: новый код без тестов на ревью не принимается. Конечно, он работает, если сроки не горят, — иначе программист рефакторит или покрывает его тестами позже.
Используйте тестовый фреймворк. В тестировании не нужно изобретать велосипед. Для популярных языков уже есть готовые решения, поэтому достаточно вбить в поиске test frameworks, и вы получите целый список. Вот, например, результат для Python:
Пишите простые тесты. Надо понимать, что происходит с входными данными и какой результат должна вернуть функция. Если непонятно — меняем нейминг и разбиваем функции на более мелкие, избавляемся от зависимостей. Пусть одна функция принимает результат, а другая возвращает. Так проще тестировать.
Допустим, у нас есть такая функция:
Её не нужно прогонять через юнит-тест, потому что тогда придётся мокать process_a, process_b и prepare_output. Тут нужен интеграционный тест, который проверит, как эти компоненты взаимодействуют между собой. Вообще, если код сложно покрывать юнит-тестами, используйте интеграционные — они проверяют общую работу системы, модуля или библиотеки.
Не забывайте про негативные тесты. Это the best practice. Что произойдёт, если передать в программу неправильные данные? Какую ошибку она выведет и выведет ли?
Покрывайте тестами все циклы и if-else. Этот совет касается кода, который нужно поддерживать. Если ему не следовать, на одной из итераций правок вы или ваш коллега просто всё сломаете.
Проверяйте качество тестов. Сделать это поможет мутационное тестирование. Мутационный фреймворк случайно меняет константы и значения в условных операторах и циклах, создаёт копию кода, в которой поочерёдно меняет условия. Например, было >= или было COUNT=3, а стало COUNT=10. Каждая замена тестируется: если код поменялся, а тесты не упали, значит, код не покрыт тестами.
На мутационное тестирование уходит много времени. Можно подключить плагин, который считает code coverage по тесту и выдаёт отчёт. Например, у нас покрыто тестами 43 тысячи строк кода, а 10 тысяч — нет. Значит, code coverage 81%. Но тут важен не только сам процент, но и качество — какие именно фрагменты кода и какими именно тестами покрыты. Например, не всё может быть под юнит-тестами — часть может перекрываться интеграционными.
Обеспечьте достаточный процент покрытия кода. Года три-четыре назад я был фанатиком стопроцентного покрытия. Конечно, безумно круто, когда ты всегда знаешь, что именно сломалось. Но в продакшне этого добиться сложно — да и не нужно. Исключение — маленькие проекты или «жёсткие» команды, для которых полное покрытие в приоритете.
На самом деле, code coverage в 70–90% — уже крутой показатель, но и меньше 70% — тоже плохо. И ещё важный момент: новый код не должен понижать уровень code coverage.
Проверить code coverage можно с помощью coveralls.io:
Coveralls принимает результаты тестов и выдаёт отчёт: показывает процент покрытия и как он изменился с последнего теста.
Не делайте хрупкие тесты. Если тест нестабильный и регулярно падает, его называют хрупким. Его результат может зависеть от дня недели, времени суток, чётности или нечётности запуска. Бывает, две функции работают параллельно и на итоговый результат влияет то, какая из них закончит выполняться первой. Такие функции лучше разбивать на несколько простых и тестировать по отдельности. Мокайте всё что нужно, чтобы сделать тест управляемым, но не переборщите — иначе код будет сложно поддерживать.
Допустим, мы написали юнит-тесты для двух функций. Но не учли, что первая функция сохраняет данные в глобалке, а вторая из-за этого меняет своё поведение. В результате первый тест проходит нормально, а второй падает или ведёт себя странно. А всё потому, что мы не сбросили состояние глобальной переменной.
Следите за скоростью тестов. Тесты должны работать быстро. Если они проверяют кусок кода 10–15 минут — разработчики устанут ждать и отключат их нафиг. Поэтому регулярно проверяйте скорость, ищите узкие места и оптимизируйте тесты. Если есть проблемы, подключитесь через дебаггер — возможно, основной код плохо оптимизирован и искать проблему нужно в продакшне.
Преимущества юнит-тестов
Если у вас ещё остались сомнения, писать юнит-тесты или нет, вот несколько аргументов за. Итак, чем полезны юнит-тесты.
Упрощают работу — находят ошибки, которые вы можете не заметить (меня это много раз спасало). Например, меняешь одну строчку, чтобы поправить логи, а ломается весь код. Благодаря тестам я узнавал об этом ещё до продакшна.
Понятно документируют код. Если вам неочевидно, как работает та или иная функция, можно пройти дальше по коду или открыть юнит-тест. По нему сразу видно, какие параметры принимает функция и что отдаёт после выполнения. Это упрощает жизнь тем, кто работает с чужим кодом.
Помогают ничего не сломать при рефакторинге. Бывает, что код написан непонятно и ты не можешь его отрефакторить, потому что наверняка что-то сломаешь в продакшне. А с тестами код можно смело рефакторить.
Упрощают разработку. Кажется, что юнит-тесты всё усложняют, ведь нужно написать в два раз больше кода — не только функцию, но и тест к ней. Но я много раз убеждался: когда пишешь код без тестов, потом тратишь гораздо больше времени на поиск и исправление ошибок.
Бывает, бац-бац — и в продакшн, а потом понеслось: исправляешь код первый, второй, третий раз. И постоянно вспоминаешь, как тестировать его вручную. У меня даже были файлики с входными данными для таких проверок. Тогда я тестировал программы вручную, по бумажке, и тратил на это уйму времени. А если бы написал юнит-тест, нашёл бы эти баги сразу и не переписывал код по несколько раз.
В коммерческой разработке без юнит-тестов никуда
Сейчас в коммерческой разработке без тестов почти не работают — а в большинстве компаний от разработчиков даже требуют покрывать код юнит-тестами. Везде, где я работал в последние несколько лет, тоже было такое правило. Ведь если в команде кто-то факапит, то может развалиться вся работа — а тестирование как раз защищает от краха.
Современные компании подписывают SLA — гарантируют работоспособность сервиса. Если продукт упадёт, бизнесу придётся заплатить деньги. Поэтому лучше подождать тестов и не катить код, который положит весь продакшн. Даже если сайт или приложение пролежат всего две минуты, это ударит по репутации и дорого обойдётся компании.
Чтобы лучше понять юнит-тесты, изучите тестовые фреймворки вашего языка. А потом найдите крупные open-source-проекты, которые их используют, и посмотрите, как они работают. Можно даже скачать проект и поиграть с тестами, чтобы глубже погрузиться в тему.
Чтобы познать тонкости разработки и тестирования приложений, лучше сразу учиться у практикующих профессионалов. Приходите в университет Skillbox, выбирайте курс и осваивайте программирование под присмотром экспертов.