Unit test что это
09 июня 2020
Модульное тестирование: что это?
Типы, инструменты.
Что такое модульное тестирование? Зачем оно нужно? Примеры, подходы, стратегия и методологии.
В этой статье вы найдете следующую информацию:
- Что такое модульное (Unit) тестирование?
- Зачем оно нужно?
- Как его провести?
- Методы модульного тестирования
- Разработка через тестирование (TDD)
- Преимущества модульного тестирования
- Недостатки модульного тестирования
- Рекомендации по модульному тестированию
В моделях разработки SDLC, STLC, V Model модульное тестирование – это первый уровень тестирования, выполняемый перед интеграционным тестированием. Модульное тестирование – это метод тестирования WhiteBox, который обычно выполняется разработчиком. На деле же из-за нехватки времени или халатности разработчиков, иногда модульное тестирование приходится проводить QA инженерам.
Зачем нужно модульное тестирование?
Отсутствие модульного тестирования при написании кода значительно увеличивает уровень дефектов при дальнейшем (интеграционном, системном, и приемочном) тестировании. Качественное модульное тестирование на этапе разработки экономит время , а следовательно, в конечном итоге, и деньги.
Модульное тестирование
Unit Testing
Интеграционное тестирование
Integration Testing
Системное тестирование
System Testing
Приемочное тестирование
Acceptance Testing
- Модульные тесты позволяют исправить ошибки на ранних этапах разработки и снизить затраты.
- Это помогает разработчикам лучше понимать кодовую базу проекта и позволяет им быстрее и проще вносить изменения в продукт.
- Хорошие юнит-тесты служат проектной документацией.
- Модульные тесты помогают с миграцией кода. Просто переносите код и тесты в новый проект и изменяете код, пока тесты не запустятся снова.
- Разработчик записывает в приложение единицу кода, чтобы протестировать ее. После: они комментируют и, наконец, удаляют тестовый код при развертывании приложения.
- Разработчик может изолировать единицу кода для более качественного тестирования. Эта практика подразумевает копирование кода в собственную среду тестирования . Изоляция кода помогает выявить ненужные зависимости между тестируемым кодом и другими модулями или пространствами данных в продукте .
- Кодер обычно использует UnitTest Framework для разработки автоматизированных тестовых случаев. Используя инфраструктуру автоматизации, разработчик задает критерии теста для проверки корректного выполнения кода, и в процессе выполнения тестовых случаев регистрирует неудачные. Многие фреймворки автоматически отмечают и сообщают, о неудачных тестах и могут остановить последующее тестирование, опираясь на серьезность сбоя.
- Алгоритм модульного тестирования:
- Создание тестовых случаев
- Просмотр / переработка
- Базовая линия
- Выполнение тестовых случаев.
Ниже перечислены методы покрытия кода:
- Заявление покрытия
- Охват решений
- Охват филиала
- Состояние покрытия
- Покрытие конечного автомата
Пример модульного тестирования: фиктивные объекты
Модульное тестирование основывается на создании фиктивных объектов для тестирования фрагментов кода, которые еще не являются частью законченного приложения. Подставные объекты заполняют недостающие части программы.
Например, у вас может быть функция, которая нуждается в переменных или объектах, которые еще не созданы. В модульном тестировании они будут учитываться в форме фиктивных объектов, созданных исключительно для целей модульного тестирования, выполненного в этом разделе кода.
Разработка через тестирование (TDD)
Модульное тестирование в TDD включает в себя широкое использование платформ тестирования. Каркас модульного тестирования используется для создания автоматизированных модульных тестов. Структуры модульного тестирования не являются уникальными для TDD, но они необходимы для него. Ниже некоторые преимущества TDD:
- Тесты написаны перед кодом
- Можно положиться на тестирование фреймворков
- Все классы в приложениях протестированы
- Быстрая и простая интеграция
- Разработчики, желающие узнать, какие функциональные возможности предоставляет модуль и как его использовать, могут взглянуть на модульные тесты, чтобы получить общее представление об API модуля.
- Модульное тестирование позволяет программисту выполнить рефакторинг кода на этапе регрессионного тестирования и убедиться, что модуль все еще работает правильно. Процедура заключается в написании контрольных примеров для всех функций и методов, чтобы в случае, если изменение вызвало ошибку, его можно было быстро идентифицировать и исправить.
- Можем тестировать части проекта, не дожидаясь завершения других.
- Не выявит всех ошибок. Невозможно оценить все пути выполнения даже в самых тривиальных программах.
- Модульное тестирование по своей природе ориентировано на единицу кода. Следовательно, он не может отловить ошибки интеграции или ошибки системного уровня.
Рекомендации по модульному тестированию
- Модульные тесты должны быть независимыми. В случае каких-либо улучшений или изменений в требованиях, тестовые случаи не должны меняться.
- Тестируйте только один модуль за раз.
- Следуйте четким и последовательным соглашениям об именах для ваших модульных тестов
- В случае изменения кода в каком-либо модуле убедитесь, что для модуля имеется соответствующий тестовый пример, и модуль проходит тестирование перед изменением реализации.
- Пофиксите все выявленные баги перед переходом к следующему этапу, как минимум в модели разработки SDLC.
- Примите подход «тест, как ваш код». Чем больше кода вы пишете без тестирования, тем больше сценариев вам придется проверять на наличие ошибок в дальнейшем.
Статья подготовлена на основе материалов сайта guru99.com
Unit testing. Модульное тестирование для новичков
Unit testing — один из обязательных инструментов в арсенале любого уважающего себя разработчика ПО, желающего сделать код более надежным и простым в обслуживании. Не каждый программист им пользуется ввиду отсутствия фундаментальных знаний о самом процессе тестирования и его методах.
Освітній курс від laba: PR-комунікації.
Побудуйте успішний образ вашого бренду.В этой статье детально рассмотрим данный вид тестирования, а также разберемся с грамотным написанием модульных кейсов.
1. Что такое модульное тестирование?
Модульное тестирование — это метод тестирования программного обеспечения при котором создаются модули, то есть небольшие части приложения, поведение каждого из которых проверяется отдельно. Модульное тестирование выполняется на этапе разработки приложения. Модулем может быть что угодно, например, процедура или функция.
Модульное тестирование состоит из трех этапов:
Інтенсивний курс від skvot: Ретуш фотографій.
Перетворіть свої знімки у шедеври.- Во-первых, инициализация небольшого фрагмента приложения, которое вы хотите протестировать.
- Для этого вызывается метод, применяемый в качестве стимула к тестируемой системе.
- Последний этап: наблюдение за поведением проверяемого модуля. Если наблюдаемое поведение соответствует ожиданиям пользователя, то модульный тест проходит. Этот пошаговый процесс также называется AAA (Arrange, Act, Assert).
Модульный тест бывает двух видов: на основе состояния, а также на основе взаимодействия. Если вы отслеживаете полученное состояние — это модульное тестирование на основе состояния.
Если тестирование происходит при использовании определенных методов — это модульное тестирование на основе взаимодействия. Пользователи часто путают модульное и интеграционное тестирование. Прежде чем продолжить обзор важно понять эту разницу.
2. Модульный тест против интеграционного теста
Целью модульного тестирования является проверка поведения каждой части программного обеспечения, независимо от других частей. Модульные тесты имеют более узкую область применения, позволяют нам охватить все случаи и гарантировать, что каждый отдельно взятый участок работает безупречно. Такое тестирование довольно легко реализовать.
С другой стороны, интеграционное тестирование подтверждает, что различные части системы нормально работают совместно в реальной среде. Это высокоуровневое тестирование, проверяющее сложные сценарии. Обычно для этого требуются внешние ресурсы, такие как веб-серверы и базы данных. Интеграционное тестирование применяют при взаимодействии между различными компонентами в условиях максимально близких к реальной среде (при помощи дополнительных инструментов).
Когда эти два вида тестирования объединяются — мы получаем высокий уровень уверенности в том, что вся система работает должным образом. Однако всегда нужно помнить о том, какой тест мы реализуем: модульный или интеграционный.
Бывают случаи, когда модульные тесты требуют наличия внешних ресурсов, таких как веб-серверы или база данных. В большинстве случаев причина кроется в плохом дизайне модульного теста. Давайте узнаем, как сделать хороший модульный тест, чтобы избежать подобных проблем.
Вдохновляючий курс від skvot: Створення текстів.
Мистецтво слова та стилю.3. Что делает хороший модульный тест?
Модульные тесты применяются для проверки различных аспектов приложения, не затрачивая много времени и усилий со стороны разработчиков.
Такие тесты:
- Работают, даже если в тестируемой системе есть ошибка. На хорошие модульные тесты не будут влиять внешние факторы, такие как окружающая среда или порядок выполнения. Если это произойдет, то это определенно недостаток дизайна.
- Забегая вперед, скажу, что хороший модульный тест ясен и рассказывает историю о поведенческом аспекте приложения. С помощью тестовых примеров легко понять, какой сценарий был протестирован. Если тест не проходит, то исправить ошибки можно быстро и без отладки кода.
Unit-тесты и тестируемая система не должны обращаться к сетевым ресурсам, файловым системам и базам данных, чтобы исключить общее влияние внешних факторов, что делает такой тест действительно модульным, а не интеграционным. Они просты в написании, и их легко поддерживать.
4. Почему именно модульное тестирование?
Иногда разработчики пропускают unit-тестирование из-за нехватки времени, не понимая, к чему это может привести. Это влечет за собой увеличение затрат на исправление дефектов во время интеграции, на бета-тестирование и последующее тестирование системы. Правильное модульное тестирование во время разработки приложения экономит время и деньги. Вот основные его преимущества:
- Вы сможете исправить дефекты на ранней стадии разработки, сэкономив ресурсы.
- Это помогает разработчику быстро разобраться с кодовой базой и быстро внести необходимые изменения.
- Хорошие модульные тесты обычно служат проектной документацией.
Динамічний курс від skvot: Візуалізація екстер’єрів у 3DS MAX.
Мистецтво в 3DS MAX.5. Как проводить модульное тестирование
Модульное тестирование делится на ручное и автоматическое. Автоматизация модульных тестов — хорошая практика, ее также можно выполнять вручную. При ручном подходе используется документ с пошаговыми инструкциями. Перечислим по пунктам все составляющие автоматизированного подхода:
- Разработчик пишет модульные тесты, чтобы проверить функциональность конкретной части приложения. Они закомментированы и будут удалены позже, после успешного развертывания приложения.
- Функция должна быть изолирована, чтобы ее можно было проверить более тщательно. Лучшая практика unit-тестирования — копировать и вставлять код в тестовую среду, вместо работы в естественной среде. Изолированный код помогает выявить и устранить зависимости между тестируемым кодом и пространствами данных.
6. Тестирование с помощью пирамиды Майка Кона
Ни один разговор о тестировании не обходится без упоминания пирамиды тестов, подробно описанную разработчиком Майклом Коном в его книге «Scrum: гибкая разработка ПО»:
Пирамида должна определять ваш подход к написанию тестов. Она показывает вам, на чем можно сосредоточить свое время. Наиболее важные выводы из диаграммы:
- Чем выше вы поднимаетесь по пирамиде, тем медленнее проходят тесты. Это приводит к увеличению продолжительности цикла обратной связи. Более длительное время цикла обратной связи приводит к увеличению времени на отслеживание причины сбоев, поскольку они обычно происходят дальше от источника реальной проблемы.
- Чем выше вы поднимаетесь по пирамиде, тем дороже становится писать и поддерживать тесты. По мере продвижения вверх по пирамиде элементы тестируемой системы и их взаимодействие становятся все более сложными.
- Наличие большего количества тестов на более низком уровне является желательной целью. Это очень желательно, но не всегда возможно. Напишите тест там, где он действительно подходит. Подробнее об этом ниже.
Определения тестов
Что касается типов тестов на каждом уровне пирамиды, то существуют разные мнения о том, что включает в себя каждый тип.
- Модульные тесты — как мы уже с вами разобрали, тестируют наименьшую единицу кода — обычно функцию, класс или структуру данных. Самым важным аспектом модульных тестов является их скорость.
- Компонентные тесты — это по сути интеграционные тесты. Их цель — выделить правильную функцию отдельного компонента.
- Интеграционные тесты обычно включают в себя тестирование взаимодействия между двумя или более компонентами системы.
- Системные тесты — служат для тестирования экземпляра (или части) вашей реальной системы. Обычно они соответствуют конфигурации тестовой среды вашей системы. Эти тесты могут быть дорогостоящими для начальной загрузки и медленными для выполнения.
- Manual или браузерные тесты — это тип системных тестов, ориентирующихся на пожеланиях конечного пользователя. Их следует ограничить сценариями тестирования, охватывающими многоэтапные или многостраничные рабочие процессы, которые невозможно эффективно протестировать другими способами.
7. Методы unit-тестирования
Ниже приведены методы покрытия кода при модульном тестировании:
- Тестирование белого ящика — с помощью пользовательского интерфейса проверяются ввод и вывод.
- Тестирование черного ящика — помогает проверить поведение различных функций, используемых в приложении.
- Тестирование серого ящика — используется для выполнения тестов, рисков и методов оценки.
8.Инструменты
Существует множество автоматизированных инструментов, помогающих при модульном тестировании. Здесь, для примера, рассмотрим самые популярные из них.
- Jtest — это плагин IDE, использующий фреймворки с открытым исходным кодом, с управляемыми и простыми действиями в один щелчок — для создания, масштабирования и поддержки модульных тестов. Автоматизация этих трудоемких аспектов модульного тестирования позволяет разработчикам больше сосредоточиться на бизнес-логике и создавать более мощные наборы тестов.
- Junit — бесплатный инструмент для тестирования, основанный на языке программирования Java. Он предоставляет утверждения для определения различных методов тестирования и проверяет данные, прежде чем вставлять их в фрагмент кода.
- NUnit — широко используемая среда тестирования, позволяющая писать скрипты вручную. Поддерживает параллельное выполнение тестов.
- JMockit — снова инструмент тестирования с открытым исходным кодом, позволяющий имитировать API с проверкой и записью синтаксиса.
- EMMA — это набор инструментов с открытым исходным кодом для анализа и составления отчетов по коду, написанному на языке Java. Предназначен для тестирования методов, строк и базовых блоков, он может обращаться к коду без какой-либо внешней библиотеки.
- PHPUnit — это популярный инструмент тестирования для программистов PHP. Инструмент позволяет разработчикам использовать предопределенные методы утверждения, чтобы убедиться, что система ведет себя определенным образом.
Это всего лишь несколько инструментов unit-тестирования, пользующихся большой популярностью на рынке технологий. Их гораздо больше, и вы можете выбрать любой из них в зависимости от ваших потребностей, требований и вкусов.
9. Разработка через тестирование (TDD)
Unit-testing при разработке предполагает широкое использование специальных фреймворков. Вот несколько фактов о том, что TDD привносит в мир модульного тестинга:
- Модульные тесты часто пишутся до самого кода.
- Применение фреймворков тестирования для написания или автоматизации модульных тестов.
- Используется для тестирования всех классов в приложении.
- Легкая и быстрая интеграция.
10. Преимущества модульного тестирования
- Модульное тестирование упрощает изменение и поддержку кода. Когда написаны хорошие модульные тесты, они могут выявлять проблемы каждый раз, когда код запускается или изменяется.
- Unit-тесты можно использовать повторно.
- Модульное тестирование ускоряет разработку. Все, что вам нужно — запустить графический интерфейс и предоставить все необходимые входные данные.
- Модульные тесты более надежны и в долгосрочной перспективе выполняются быстрее. Усилия, прилагаемые для написания и исправления дефектов во время модульного тестирования, намного меньше по сравнению с усилиями, необходимыми для исправления ошибок во время тестирования системы или приемочного тестирования.
- Менее затратное по времени и другим ресурсам.
- Модульное тестирование упрощает отладку. Если тест не проходит, последние изменения необходимо снова отладить. Тестирование на более высоких уровнях позволяет сканировать изменения, внесенные за несколько дней, недель, месяцев и т. д.
- Такой подход улучшает дизайн кода и позволяет проводить его рефакторинг. В процессе написания тестовых примеров для методов или функций всякий раз, когда изменения вызывают ошибку, ее можно быстро идентифицировать или при необходимости исправить.
- Модульные тесты при интеграции также дают равенство сборки.
- Разработчики могут понять, какие функции выполняет конкретный модуль, и взглянуть на модульные тесты, чтобы получить базовое представление об API.
- Поскольку unit-тесты являются модульными, можно тестировать выбранную часть кода, не дожидаясь завершения другой.
11. Недостатки модульного тестирования
- Модульное тестирование не выявляет всех ошибок в программе.
- Не может оценить все пути выполнения, даже в тривиальных программах.
- В основном фокусируется на единицах измерения и не может выявлять ошибки интеграции на более широком уровне.
Общее правило таково: unit-тестирование следует выполнять в сочетании с другими тестами, чтобы получить более точные результаты.
Правила работы с unit-тестами:
- Каждый модуль должен быть независимым. Любое изменение в нем не должно влиять на другие юниты.
- Используется для одновременной проверки только одного кода.
- Вы всегда должны использовать четкие и последовательные соглашения об именах.
- Для каждого модуля должен быть отдельный тестовый пример перед отправкой на реализацию.
- Ошибки следует исправить заранее, прежде чем переходить к следующему этапу в SDLC (System/Software Development Life Cycle).
- Чем больше кода вы напишете, тем больше у вас будет путей для проверки на наличие ошибок.
Заключение
Unit-тесты могут быть простыми или сложными в зависимости от характера тестируемого объекта, инструментов и стратегий, используемых для тестирования. Здесь можно быть уверенным только в одном: модульное тестирование сделает вашу программу более надежной и функциональной по сравнению с непроверенными приложениями.
Несколько полезных видеороликов по теме:
Unit-тестирование
Unit-тестирование — это разновидность тестирования в программной разработке, которое заключается в проверке работоспособности отдельных функциональных модулей, процессов или частей кода приложения. Unit-тестирование позволяет избежать ошибок или быстро исправить их при обновлении или дополнении ПО новыми компонентами, не тратя время на проверку программного обеспечения целиком.
«IT-специалист с нуля» наш лучший курс для старта в IT
Зачем проводится unit-тестирование
Основной смысл модульного тестирования заключается в том, чтобы избежать накапливания ошибок в будущем, а также исключить регрессию уже отлаженных модулей. Например, у вас есть в целом готовое приложение, к которому необходимо добавить несколько новых функций или процессов. Если сначала выполнить интеграцию компонентов, а потом протестировать полностью «собранное» ПО, то ошибки в дополнениях могут привести к нестабильной работе всего приложения. Чтобы этого не произошло, легче протестировать добавляемые функции изолированно, а после устранения всех багов интегрировать их в программу.
Профессия / 8 месяцев
IT-специалист с нуляПопробуйте 9 профессий за 2 месяца и выберите подходящую вам
Таким образом, unit-тестирование решает следующие задачи:
- поиск и исправление ошибок на ранних стадиях разработки программного продукта и, следовательно, снижение затрат в дальнейшем;
- лучшее понимание разработчиками базового кода проекта, более простая и быстрая корректировка продукта;
- повторное использование кода, в том числе с переносом (вместе с тестами) в другие продукты;
- использование юнит-тестов как проектной документации, по которой разработчики, не знакомые с кодом, могут понять принцип его работы.
Преимущества unit-тестирования
Применять модульное тестирование при разработке программных продуктов рекомендуется по следующим причинам:
- Простота. Написать тест для отдельного модуля проще, чем для приложения в целом. Соответственно, если нужно проверить не всю программу, а лишь ее часть (например, вышедшее обновление или патч), то можно использовать модульное тестирование, предварительно изолировав проверяемый фрагмент кода. Хотя интеграционное тестирование нужно будет провести в любом случае.
- Информативность. Хорошо составленный тест помогает разработчикам понять API приложения, функционал модуля, особенности его использования. Особенно это полезно в том случае, если при работе над проектом произошла смена ответственных за разработку и проверку специалистов.
- Параллельная разработка. Модульное тестирование позволяет проверить работу одного компонента приложения независимо от других. Благодаря этому можно параллельно разрабатывать различные программные модули, тем самым сократив время на создание и отладку продукта.
- Возможность повторного использования. Создав однажды тест для проверки отдельного модуля, разработчик может вернуться к нему позднее, чтобы протестировать работу компонента еще раз. Регрессионное тестирование состоит в написании контрольных примеров для всех функций, которые помогают выявить ошибки, вызванные внесенными изменениями.
Недостатки unit-тестирования
Несмотря на свои достоинства, модульное тестирование не является панацеей от всех болезней кода:
- Модульное тестирование не гарантирует, что будут найдены все ошибки. Причина в том, что даже в относительно простых программах невозможно предугадать все сценарии их выполнения.
- Unit-тестирование применяется к изолированным фрагментам кода, поэтому может выявить только ошибки проверяемого модуля. Оно не способно показать баги, возникающие при интеграции модуля с другими компонентами приложения. Также unit-тестирование не способно выявить системные ошибки продукта в целом.
Модульное и интеграционное тестирование
Часто unit-тестирование путают с интеграционным, но это два разных по реализации и назначению уровня проверки программного обеспечения. Отличительные особенности модульного тестирования:
- узкая специализация — проверке подвергаются отдельные модули, а не все приложение в целом;
- простая реализация — тестирование модулей по отдельности (особенно при параллельной разработке) достаточно легкое в плане реализации, может проводиться без привлечения внешних ресурсов.
Напротив, интеграционное тестирование отличается следующими особенностями:
- общей направленностью — проверке подвергается не каждый модуль, а вся система, включая основное ядро и функциональные компоненты;
- сложностью — интеграционное тестирование проводится в среде, максимально близкой к реальной, поэтому требует привлечения внешних ресурсов (баз данных, веб-серверов).
В реальной практике эти два уровня тестирования не противопоставляются, а дополняют друг друга. Проверка каждого модуля снижает количество багов, которые обязательно проявятся при интеграции компонентов. А интеграционное тестирование позволит оценить взаимодействие программных модулей друг с другом и ядром приложения.
Курс для новичков «IT-специалист
с нуля» – разберемся, какая профессия вам подходит, и поможем вам ее освоитьВиды и методы модульного тестирования
Виды
Ручное. Проводится максимально просто по заранее составленному документу с пошаговыми инструкциями. Однако такой подход возможен только с небольшими и несложными фрагментами кода и к тому же даже в этом случае он занимает много времени.
Автоматизированное. Unit-тестирование заключается в использовании специально разработанных тестовых сред, которые проверяют работу модуля и выявляют в ней ошибки. Такой подход имеет следующие особенности:
- Для каждой функциональной части приложения пишется отдельный модульный тест. Применять один и тот же тест для проверки разных компонентов нельзя.
- Проверяемый модуль должен быть изолирован от ядра приложения и других компонентов, чтобы исключить искажение результатов тестирования. Поэтому модульная проверка проводится не в естественной среде, а в специально разработанной тестовой.
- Использование автоматизированной тестовой среды позволяет смоделировать различные сценарии поведения кода. Если по ходу проверки были выявлены серьезные ошибки, такая система останавливает процесс до их устранения разработчиком, а потом снова запускает тест.
Методы
«Черного ящика». В этом случае тестирование происходит по входным и выходным сигналам модуля без анализа структуры его кода. Чаще всего такой метод применяется, когда проверку выполняет разработчик, который не участвовал в создании компонента.
«Белого ящика». Суть этого метода в том, что тестируются внутренняя структура модуля, его возможности, особенности поведения, реакция на входные сигналы и т.д. Иными словами, компонент изначально полностью прозрачен и понятен разработчику, который оценивает все внутренние и внешние аспекты его работы.
Для понимания unit-тестирования рассмотрим подробнее, как оно происходит по методу «белого ящика». В этом случае оно состоит из трех этапов:
- Анализ отдельного модуля. На этой стадии тестирования разработчик изучает внутреннюю структуру кода, функционал и поведение исследуемого компонента. Данный этап пройдет значительно быстрее, если программист сам создавал модуль или участвовал в его создании. Если нет — ему придется поднимать соответствующую документацию, консультироваться с создателем тестируемого фрагмента кода. Главная задача заключается в полном понимании того, как устроен и работает проверяемый программный компонент.
- Создание кейс-теста. Это сценарий или модель, которые должны показать, как проверяемый модуль ведет себя в реальной обстановке. Кейс-тесты создают искусственную среду, максимально близкую к реальной, но без привлечения внешних ресурсов, которые обычно задействуются в работе программного обеспечения (веб-серверов, баз данных и т.д.).
- Тестирование модуля. Проверяемый компонент, предварительно изолированный от ядра приложения и других модулей, запускается в кейс-тесте. При этом разработчик смотрит на то, как он реагирует на входные сигналы, как работает сам код, соответствует ли его структура выполняемым задачам, анализирует возможные ошибки и т.д.
Часто к одному и тому же компоненту ПО разработчик применяет различные методики тестирования. Указанные методы «черного и белого ящиков» не исчерпывают всех методик и инструментов проверки. Зачастую разработчик создает под каждый проект уникальные способы тестирования, учитывающие особенности программного продукта.
Разработка через тестирование
Стандартна ситуация, когда разработчик сначала написал код, а затем создает под него тест и выполняет проверку. Но в программировании часто используется и обратный процесс: сначала разрабатывается тест, а модуль создается на его основе. Такой подход называется «разработка через тестирование». Суть его в том, чтобы с помощью заранее написанного теста определить требования к будущему программному компоненту. Цикл разработки через тестирование насчитывает несколько этапов:
- Добавление теста. Оно происходит перед добавлением каждой новой функции в программу. Написанный тест не запускается по причине того, что проверяемый фрагмент кода еще не написан. Если тестирование сработало — значит, аналогичная или похожая функция в программе уже есть или тест написан некорректно. Сам тест тоже представляет собой программу, поэтому разработчик предварительно должен четко понять, какие результаты она должна показать в случае успешного тестирования.
- Написание кода. Ориентируясь на то, как должна себя повести тест-программа в «идеальном» случае, разработчик пишет код самого модуля. Причем он не обязан быть сразу совершенным — все неточности будут отшлифованы в последующих циклах разработки. Главное, что требуется от кода, — это прохождение теста. Как только разрабатываемый фрагмент написан, он прогоняется через тест-программу и анализируется.
- Рефакторинг. Убедившись, что написанный модуль успешно проходит тест, разработчик проверяет его на дублирование, неточности, мусорный код и т.д. Задача на этом этапе — максимально очистить фрагмент, сделать его более прозрачным, простым и понятным.
Разработка через тестирование не ограничивается одним циклом: они повторяются каждый раз при добавлении в приложение новых функций, процессов или других объектов. Если в очередной итерации ранее проходивший тестирование код вдруг выдал ошибку, разработчик всегда может откатить внесенные изменения, которые ее вызвали.
Этот метод разработки имеет свои преимущества:
- Код становится более простым и понятным, так как пишется под конкретные требования, заданные в тесте.
- Сокращается время разработки, в том числе за счет более частого использования отката модуля к работающей версии, чем отладки неработающей.
- Дизайн программы становится более удобным для пользователей, так как продумывается заранее, до написания кода, а не подгоняется под него.
- Снижается количество багов, так как разработчик изначально знает, что хочет получить от своего кода, а не использует метод проб и ошибок.
- Заранее написанный тест можно использовать в дальнейшем в качестве проектной документации к программному продукту.
Рекомендации к unit-тестам
Чтобы модульное тестирование было максимально эффективным, тесты должны:
- соответствовать конкретному модулю — нельзя применять один и тот же тест для тестирования разных по назначению и реализации программных компонентов;
- быть автоматизированными — тест лучше вписать в сам код, тогда он будет запускаться автоматически и сильно упростит жизнь разработчику;
- быть своевременными — если тест нельзя написать до разработки самого кода, его лучше создавать параллельно, что сэкономит много времени в дальнейшем;
- отвечать основным задачам — при написании теста не нужно стараться учесть все возможные сценарии, лучше сосредоточиться сначала на основных, а остальные дополнять по мере необходимости;
- иметь хорошее название — описывающее, что именно тестируется, в каких условиях и с каким желаемым результатом.
Когда не стоит проводить unit-тестирование
Модульное тестирование — не универсальный инструмент проверки программного продукта. В некоторых ситуациях оно лишь отнимет время и силы, не показав значимого результата, например:
- при тестировании сложных и разветвленных алгоритмов, таких как красно-черное дерево, придется разработать большое число тестов, что существенно усложнит и замедлит проверку;
- отсутствии четких результатов — например, в математическом моделировании природных процессов, настолько сложных, что их «выход» невозможно спрогнозировать, а можно только описать в виде интервалов вероятных значений;
- тестировании кода, взаимодействующего с системой, — например, модуля, связанного с портами, таймерами и другими «нестабильными» компонентами, от которых его сложно изолировать;
- проверке всего приложения — модульное тестирование не покажет ошибки интеграции, баги ядра и другие аспекты, не относящиеся непосредственно к конкретному модулю;
- недостаточной квалификации самого разработчика и низкой культуре программирования, так как модульное тестирование работает только при строгом соблюдении технологии, постоянном отслеживании всех вносимых в модуль изменениях.
Unit-тестирование окажется бесполезным и при проверке максимально простого кода. Точнее, оно сработает и покажет правильный результат, но сил на написание теста уйдет больше, чем на «ручной» анализ модуля.
Unit-тестирование — это эффективный и полезный инструмент, позволяющий избежать накопления ошибок при разработке программного обеспечения и сильно упрощающий проверку на более высоких уровнях (интеграционную, системную, приемочную).
IT-специалист с нуля
Наш лучший курс для старта в IT. За 2 месяца вы пробуете себя в девяти разных профессиях: мобильной и веб-разработке, тестировании, аналитике и даже Data Science — выберите подходящую и сразу освойте ее.
Статьи по теме:
Что такое юнит-тесты и почему они так важны
Бывает, кодишь 10 минут, а дебажишь 2 часа. Чтобы такого не случилось, пилите юнит-тесты. Михаил Фесенко рассказал, как их правильно готовить.
Oli Scarff / Staff / GettyImages
Мария Даровская
Журналист, коммерческий автор и редактор. Пишет про IT, цифровой маркетинг и бизнес.
Сайт: darovska.com.
об авторе
Фесенко Михаил, можно просто Фес. Разработчик, раньше работал системным администратором, пишет на чём скажут, но пока писал на PHP, Go, Python, Bash. Сейчас работает в «Яндекс.Облаке», до этого работал во «ВКонтакте». Любит жену, кино и снимать видео =)
Ссылки
Юнит-тест (unit test), или модульный тест, — это программа, которая проверяет работу небольшой части кода. Разработчики регулярно обновляют сайты и приложения, добавляют фичи, рефакторят код и вносят правки, а затем проверяют, как всё работает.
Тестировать систему целиком после каждого обновления — довольно муторно и неэффективно. Поэтому обновлённые или исправленные части кода прогоняют через юнит-тесты.
Особенности юнит-тестов
На практике используют разные тесты — их разделяют по уровню абстракции с помощью пирамиды Майка Кона :
Чем выше тест в пирамиде, тем больше частей программы он затрагивает. Высокоуровневые тесты «ближе к бизнесу»: они проверяют бизнес-логику и пользовательские процессы. А те, что внизу пирамиды, помогают найти проблемы в отдельных частях кода. Например, какую-нибудь функцию, которая генерирует имя файла.
Большая часть тестов работает на верхних уровнях и не позволяет точечно отлавливать баги. Те же интеграционные тесты проверяют, как взаимодействуют между собой разные системы. А Е2Е -тесты исследуют процессы со стороны пользователя: например, когда он регистрируется и логинится на сайте.
В отличие от них, юнит-тесты нужны в следующих случаях:
- если код непонятен — на ревью возникли вопросы по его работе;
- если код часто меняется — чтобы не проверять его вручную;
- если обновления в одной части кода могут сломать что-то в другой части.
Некоторые программисты пишут только юнит-тесты, а на интеграционные или E2E-тесты жалеют времени. На самом деле нужно покрывать систему всеми видами тестов, чтобы знать, как взаимодействуют друг с другом разные части программы, какие промежуточные результаты они выдают. Но в то же время, если юнит-тесты показывают ошибку, её покажет и интеграционный, и E2E-тест.
Процесс юнит-тестирования
Для юнит-тестирования подключают тестовые фреймворки — они позволяют «мокать», то есть имитировать функции. В коде больших проектов много зависимостей: одна функция вызывает другую и влияет на разные части программы. Но, как правило, достаточно проверить функции «в вакууме», отдельно от остального кода. Для этого и нужен тестовый фреймворк — он моделирует условия, в которых функция А вызывает функцию Б изолированно от других функций.
Простой пример: у нас есть функция на Go, которая получает id бэкапа и возвращает имя бэкап-файла:
Протестируем её с помощью набора входных и выходных данных. Они должны учитывать все ситуации, поэтому не забываем про негативные кейсы — когда программа возвращает ошибку. Вот набор тестовых данных:
В первую очередь я прописал запрещённые данные (-1 и 0) и слишком большое значение (10200300). Когда пользователь их вводит, функция не должна возвращать результат. Вместо этого мы ждём сообщения об ошибке: BAD_ID или BACKUP_ID_TOO_BIG. Когда же функция получает валидный id, она выводит отформатированное имя файла, например Backup#000010.
А вот и код самого теста:
Порой код для тестирования даже больше основного — и это норма. Но иногда всё-таки стоит задуматься, на самом ли деле тест должен быть таким объёмным. Я бы посоветовал покрывать тестами только те фрагменты кода, которые вы планируете менять. Или сложные части, которые, скорее всего, придётся чинить или поддерживать.
Некоторые разработчики мокают всё подряд. Из-за этого тесты становятся хрупкими, а код — сложным и непонятным. На самом деле для юнит-тестирования достаточно лишь немного переписать код, а огромные функции лучше разбить на более мелкие.
В старой хорошей книге «Экстремальное программирование» есть классная мысль: сначала пишите тест, а только потом программу. Это клёвый подход, но не все могут так делать (а кто-то просто не хочет тратить время).
Как покрыть код юнит-тестами
Есть разработчики, которые не проводят модульное тестирование: «Ой, у нас большой проект, и переписать 1000 строк под тесты или замокать их — слишком запарно». На самом деле покрыть код тестами несложно. Вот несколько советов.
Написали код — напишите тест. Я видел много проектов, в которых юнит-тесты писали по принципу «новый код — новый тест». Думаю, это правильный подход, ведь, когда добавляешь в программу что-то новое, она часто ломается. К тому же, если писать тесты сразу, не придётся переворачивать весь код, когда он разрастётся.
Есть более жёсткий принцип: новый код без тестов на ревью не принимается. Конечно, он работает, если сроки не горят, — иначе программист рефакторит или покрывает его тестами позже.
Используйте тестовый фреймворк. В тестировании не нужно изобретать велосипед. Для популярных языков уже есть готовые решения, поэтому достаточно вбить в поиске test frameworks, и вы получите целый список. Вот, например, результат для Python:
Пишите простые тесты. Надо понимать, что происходит с входными данными и какой результат должна вернуть функция. Если непонятно — меняем нейминг и разбиваем функции на более мелкие, избавляемся от зависимостей. Пусть одна функция принимает результат, а другая возвращает. Так проще тестировать.
Допустим, у нас есть такая функция:
Coveralls принимает результаты тестов и выдаёт отчёт: показывает процент покрытия и как он изменился с последнего теста.
Не делайте хрупкие тесты. Если тест нестабильный и регулярно падает, его называют хрупким. Его результат может зависеть от дня недели, времени суток, чётности или нечётности запуска. Бывает, две функции работают параллельно и на итоговый результат влияет то, какая из них закончит выполняться первой. Такие функции лучше разбивать на несколько простых и тестировать по отдельности. Мокайте всё что нужно, чтобы сделать тест управляемым, но не переборщите — иначе код будет сложно поддерживать.
Если в коде есть глобалки или стейты , в них между вызовами функции сохраняется стейт/кэш и другая информация. Очищайте их перед каждым тестом и убедитесь, что тесты не зависят друг от друга.
Допустим, мы написали юнит-тесты для двух функций. Но не учли, что первая функция сохраняет данные в глобалке, а вторая из-за этого меняет своё поведение. В результате первый тест проходит нормально, а второй падает или ведёт себя странно. А всё потому, что мы не сбросили состояние глобальной переменной.
Следите за скоростью тестов. Тесты должны работать быстро. Если они проверяют кусок кода 10–15 минут — разработчики устанут ждать и отключат их нафиг. Поэтому регулярно проверяйте скорость, ищите узкие места и оптимизируйте тесты. Если есть проблемы, подключитесь через дебаггер — возможно, основной код плохо оптимизирован и искать проблему нужно в продакшне.
Преимущества юнит-тестов
Если у вас ещё остались сомнения, писать юнит-тесты или нет, вот несколько аргументов за. Итак, чем полезны юнит-тесты.
Упрощают работу — находят ошибки, которые вы можете не заметить (меня это много раз спасало). Например, меняешь одну строчку, чтобы поправить логи, а ломается весь код. Благодаря тестам я узнавал об этом ещё до продакшна.
Понятно документируют код. Если вам неочевидно, как работает та или иная функция, можно пройти дальше по коду или открыть юнит-тест. По нему сразу видно, какие параметры принимает функция и что отдаёт после выполнения. Это упрощает жизнь тем, кто работает с чужим кодом.
Помогают ничего не сломать при рефакторинге. Бывает, что код написан непонятно и ты не можешь его отрефакторить, потому что наверняка что-то сломаешь в продакшне. А с тестами код можно смело рефакторить.
Упрощают разработку. Кажется, что юнит-тесты всё усложняют, ведь нужно написать в два раз больше кода — не только функцию, но и тест к ней. Но я много раз убеждался: когда пишешь код без тестов, потом тратишь гораздо больше времени на поиск и исправление ошибок.
Бывает, бац-бац — и в продакшн, а потом понеслось: исправляешь код первый, второй, третий раз. И постоянно вспоминаешь, как тестировать его вручную. У меня даже были файлики с входными данными для таких проверок. Тогда я тестировал программы вручную, по бумажке, и тратил на это уйму времени. А если бы написал юнит-тест, нашёл бы эти баги сразу и не переписывал код по несколько раз.
В коммерческой разработке без юнит-тестов никуда
Сейчас в коммерческой разработке без тестов почти не работают — а в большинстве компаний от разработчиков даже требуют покрывать код юнит-тестами. Везде, где я работал в последние несколько лет, тоже было такое правило. Ведь если в команде кто-то факапит, то может развалиться вся работа — а тестирование как раз защищает от краха.
Современные компании подписывают SLA — гарантируют работоспособность сервиса. Если продукт упадёт, бизнесу придётся заплатить деньги. Поэтому лучше подождать тестов и не катить код, который положит весь продакшн. Даже если сайт или приложение пролежат всего две минуты, это ударит по репутации и дорого обойдётся компании.
Чтобы лучше понять юнит-тесты, изучите тестовые фреймворки вашего языка. А потом найдите крупные open-source-проекты, которые их используют, и посмотрите, как они работают. Можно даже скачать проект и поиграть с тестами, чтобы глубже погрузиться в тему.
У фреймворков разный подход к написанию тестов, вызову методов, мокам и неймингу. Плюс у каждого из них есть сторонники и хейтеры, поэтому пробуйте и выбирайте. Главное — чтобы фреймворк хорошо мокал ваш код. Например, если у вас специфичный ORM , убедитесь, что фреймворк умеет с ним работать.
Чтобы познать тонкости разработки и тестирования приложений, лучше сразу учиться у практикующих профессионалов. Приходите в университет Skillbox, выбирайте курс и осваивайте программирование под присмотром экспертов.
Основатель консалтинговой фирмы Mountain Goat Software, автор книг по Java, C++ и Scrum.
Сквозное тестирование, при котором происходит подробная эмуляция пользовательской среды.
Процент покрытия кода тестами.