Что такое юнит-тестирование?
Модульное тестирование - самоочевидное слово, если человек понимает, что подразумевается под Модулем. Единица - это наименьший возможный кусок кода, который может быть логически изолирован от системы. Это означает, что любой фрагмент кода, который может принимать входные данные, выполнять задачу и генерировать выходные данные, даже если он не зависит от всей системы или решения, может называться Единицей. Тестирование этого фрагмента кода для генерации ожидаемого вывода на заданном наборе входных данных называется модульным тестированием.
Типы юнит-тестирования
Давайте обсудим некоторые из типов модульного тестирования.
1) Ручное тестирование
Ручное тестирование кода требует, чтобы разработчик вручную отлаживал каждую строку кода и проверял ее на точность. Также может потребоваться пошаговый набор инструкций, если функциональность сложна.
2) Автоматизированное тестирование
При автоматизации тестирования разработчик пишет код для тестирования кода. Этому, как правило, помогают через платформы модульного тестирования, которые не развернуты в производстве. В других случаях разработчик может написать тестовый код без инфраструктуры и закомментировать его перед развертыванием.
Ручное тестирование, очевидно, занимает много времени в большинстве случаев. Но в некоторых случаях, когда написание автоматических тестовых примеров для каждого сценария невозможно, руководство часто является предпочтительным методом.
Почему юнит тестирование важно?
Чтобы понять важность модульного тестирования, нам нужно взглянуть на более широкую картину. Это часть жизненного цикла разработки программного обеспечения. Давайте кратко рассмотрим другие части, чтобы лучше понять роль модульного тестирования.
Изображение выше является простой иллюстрацией нормального жизненного цикла разработки программного обеспечения и процессов тестирования, связанных с ним. Излишне говорить, что в зависимости от структуры проекта весь процесс зависит от добавления и удаления определенных компонентов. Однако процесс тестирования, безусловно, включает четыре типа, как описано ниже:
- Модульное тестирование - элементарный уровень всего процесса тестирования. Это выполняется разработчиком компонента или любым из его коллег. В последнем случае его часто называют Peer Testing в мире программного обеспечения.
- Интеграционное тестирование - тестирование компонента модуля с его непосредственным родительским модулем. Цель состоит в том, чтобы проверить, хорошо ли интегрируется компонентный компонент с другими компонентами и не вызвал ли он неисправность какого-либо другого компонента.
- Системное тестирование - тестирование всей системы, когда компонент блока находится на своем месте.
- Приемочное тестирование - обычно проводится бизнесом / клиентами, оно проверяет, соответствует ли результат функциональности, ожидаемой конечным пользователем.
Таким образом, очень хорошо видно, что все процессы тестирования основаны на элементарном уровне тестирования. Если элементарный уровень тестирования не выполнен, все остальные тесты могут привести к тщетным результатам.
Теперь скажем, у вас есть код, который состоит из двух частей
- Рассчитать сложный процент.
- Добавьте проценты к основной сумме и рассчитайте выплату по срокам погашения.
Предположим, вы не тестировали модули ни одного из этих компонентов и приступили непосредственно к тестированию системы. При тестировании системы возникает ошибка, что значение срока погашения является неправильным. Теперь какая часть кода имеет ошибку?
- Это может быть при расчете процентов.
- Это может быть в применении логики составления.
- Это может быть в дополнение к процентам к основной сумме.
Посмотрите, как это увеличивает усилия сейчас. Всего этого можно было бы избежать, если бы оба компонента кода прошли модульное тестирование.
Почему юнит тестирование важно?
- Исправляет ошибки только на ранней стадии разработки. Это экономит много времени, усилий и затрат. Представьте, что если бы не было проведено модульных тестов, код был бы передан команде обеспечения качества для очень простых вопросов.
- Хорошие юнит-тесты также служат целям подробной документации. Когда разработчик пишет примеры модульных тестов, он непреднамеренно пишет ожидаемую функциональность кода. Это просто ничего, кроме документации, объясняющей работу кода.
- Это позволяет легко модифицировать и поддерживать код. После внесения каких-либо изменений в код, повторного запуска тестов и альта все дефекты обнаруживаются без проблем.
- Это также обеспечивает модульность. Модульные тесты выполняются на отдельных компонентах, что означает, что код должен быть максимально детализированным. Это гарантирует, что код удачно разделен на модули.
Другая сторона монеты
У него тоже есть некоторые недостатки. Хотя преимущества перевешивают недостатки и всегда рекомендуется проводить модульное тестирование кода, все же имеет смысл знать обе стороны одной и той же монеты.
- Модульное тестирование, каким бы тщательным оно ни было, иногда может не обнаружить все ошибки в самом тривиальном коде. Просто невозможно оценить все пути выполнения. Таким образом, модульные тесты часто представляют собой прямой сценарий «счастливого пути» и негативных сценариев.
- Требуется, чтобы разработчик думал нестандартно и попытался взломать свой код. Это часто сложно, так как восприятие разработчика смещено в сторону кода.
Инструменты модульного тестирования
В отрасли существует несколько инструментов, помогающих автоматизировать тестовые случаи. Как и цель, они облегчают разработчику написание и выполнение юнит-тестов. Существует целый мир фреймворков для модульного тестирования. Некоторые из самых популярных и широко используемых инструментов перечислены ниже.
JUnit
JUnit - это бесплатный инструмент для тестирования Java. Он автоматически включается во многие шаблоны проектов, доступные в различных средах разработки для разработки на Java. Что делает JUnit особенным, так это то, что он сначала проверяет данные, а затем проверяет код после вставки данных в него. Он также предоставляет утверждения для определения методов испытаний.
NUnit
NUnit для .Net, как JUnit для Java. Он имеет все характерные особенности JUnit, но для разработки на языке программирования .Net. Он также поддерживает параллельное выполнение тестов.
PHPUnit
Подобно JUnit и NUnit, PHPUnit - это инструмент для разработчиков PHP. Он также поддерживает все элементарные функции хорошего инструмента тестирования.
XUnit
Еще одна структура, которая является более общей, чем ее аналоги, - это XUnit. Он поддерживает несколько языков, таких как C ++, C #, ASP.Net и т. Д. Он также имеет функции, аналогичные другим инструментам, доступным на рынке.
Jtest
Parasoft Jtest - это сторонний плагин, который использует фреймворки с открытым исходным кодом, такие как JUnit, и добавляет решения в один клик, чтобы сделать жизнь проще. С помощью Jtest вы можете автоматически генерировать тестовые коды для вашего кода всего несколькими щелчками мыши. Автоматизируя эти задачи, разработчик может свободно работать с бизнес-логикой тестовых случаев.
QUnit
Очень популярная среда модульного тестирования JavaScript. Он может тестировать код JavaScript как на стороне клиента, так и на стороне сервера.
жасмин
Другой очень широко используемый инструмент тестирования для JavaScript-фреймворков. Он имеет большую поддержку сообщества для Angular, React и т. Д.
JMockit
JMockIt - это инструмент с открытым исходным кодом, который также поддерживает макетирование вызовов API с использованием синтаксиса записи и проверки.
Пример модульного теста
Основным требованием для любого модульного теста является код, подлежащий тестированию. Предположим, у нас есть функция, которая проверяет правильность телефонных номеров (с точки зрения формата) или нет. В зависимости от географического положения этот критерий также может варьироваться. Итак, мы не будем подчеркивать критерии. Скорее мы сосредоточимся на модульном тесте.
public class PhoneValidator
(
public bool IsPhoneValid(string phone)
(
/* write some code to verify if the phone is valid or not. return true, if the phone is valid. return false, if invalid. */
)
)
Теперь нам нужно протестировать этот кусок кода.
Мы можем либо проверить это вручную, вставляя различные значения и проверяя вывод. Это может показаться простым на первый взгляд, но будет повторной задачей, если в код будут внесены какие-либо изменения.
В качестве альтернативы, мы можем написать пример модульного теста, который может служить моим валидатором, пока бизнес-логика остается неизменной. Модульный тест не изменится, даже если мы изменим код. Итак, давайте напишем пример модульного теста для приведенного выше кода.
public void TestPhoneValidator()
(
string validPhone = "(123) 456-7890";
string invalidPhone = "123 45"
PhoneValidator validator = new PhoneValidator();
Assert.IsTrue(validator.IsPhoneValid(valid phone));
Assert.IsFalse(validator.IsPhoneValid(invalidPhone));
)
Так как же работает приведенный выше код модульного теста? Обратите внимание на два утверждения Assert. Они проверяют, что тест пройден только в том случае, если две строки получают истину и ложь от соответствующих вызовов функций IsPhoneValid.
Вы спросите, каковы преимущества написания этого теста? Что ж, если у вас есть тысячи телефонных номеров для проверки в любом реальном сценарии, вам не нужно проверять вручную каждый раз, когда отладчик нажимает код. Просто вызовите тестовый код тысячи раз, и он скажет вам, какие тесты пройдены, а какие - нет. Теперь вам нужно только осмотреть неисправных.
Советы по модульному тестированию
- Всегда используйте инструмент или платформу, поддерживающую ваш язык. Инструменты облегчают разработку юнит-тестов. В противном случае вы можете приложить дополнительные усилия.
- Хотя это рекомендуется для всего, иногда удобно пропустить простые коды, которые напрямую не влияют на поведение системы. Например, коды получения и установки могут быть менее сфокусированы.
- Никогда не пропускайте коды, которые напрямую влияют на систему или имеют решающее значение для реализации бизнес-логики.
- Используйте тестовые данные, которые напоминают производственные данные.
- Изолируйте свой код. Если ваш код зависит от данных из базы данных, не пишите контрольный пример для вызова базы данных и получения значений. Вместо этого создайте интерфейс и смоделируйте вызовы API и базы данных.
- Перед исправлением ошибки, возникающей в результате модульного тестирования, напишите тестовый пример, который обнаруживает дефект. Для этого есть три причины:
- Вы сможете отследить дефекты регрессии, возникающие из вашего исправления.
- Ваш тестовый пример стал более полным.
- Часто разработчик слишком ленив, чтобы обновить свои тестовые сценарии после написания.
- В дополнение к написанию тестовых случаев, которые проверяют бизнес-логику, напишите также случаи, которые проверяют производительность вашего кода. В частности, когда коды включают в себя циклы, производительность является наиболее уязвимой областью.
То, что нужно запомнить
- Модульные тесты должны быть независимы от
- Тестируемый код. Любые изменения в коде не должны требовать изменения в модульном тесте, если только не изменяется сама бизнес-логика. Например, если логика теперь требует, чтобы действительный номер телефона всегда начинался с «+», тогда необходимо изменить пример модульного теста, в противном случае - нет.
- Другой код - не должно быть никакого взаимодействия или зависимости с любым другим фрагментом кода, значением базы данных или чем-то подобным. Блок должен быть изолирован во время тестирования.
- Следуйте четким и последовательным соглашениям об именах для ваших тестовых случаев. Это облегчает отслеживание сценариев. Вы также можете использовать инструменты контроля версий, чтобы отслеживать ваши тесты.
- Никогда не передавайте свой код на следующий этап, пока он не будет выполнен, ошибки исправлены и проверены повторно.
- Самое главное, сделать это привычкой. Это практика кодирования, которая должна быть внедрена. Чем больше вы кодируете без модульного тестирования, тем более подвержен ошибкам ваш код.
Карьера в модульном тестировании
Хотя юнит-тестирование не является полем в целом, все же это дополнительная стрелка в вашем колчане. Это хорошая практика кодирования, и когда хорошие кодеры не предпочтительны?
Вывод
Можно сделать вывод, что неоспоримо модульного тестирования могут быть простыми, иногда и сложные другие времена. Это когда инструменты и рамки приходят вам на помощь. Даже после завершения модульного тестирования код не полностью защищен от ошибок. Именно тогда начинаются процедуры тестирования следующего уровня. Среди всех этих неопределенностей, единственное, что определенно, это то, что необходимо модульное тестирование.
Рекомендуемые статьи
Это было руководство по модульному тестированию. Здесь мы обсудили важность, советы, инструменты, карьеру и типы модульного тестирования с его примерами. Вы также можете просмотреть наши другие предлагаемые статьи, чтобы узнать больше -
- Тестирование Интервью Вопросы
- Приложение для веб-тестирования
- Жизненный цикл дефекта при тестировании программного обеспечения
- Карьера в тестировании программного обеспечения
- Список тестовых фреймворков для Java