Модульные тесты работают как начальный контроль качества и эффективности кода. Через них мы можем проверить, как работает блок кода и правильно ли он это делает. Тесты стремятся заставить поведение кода анализировать его ответы и внутреннее функционирование.
Когда мы думаем о модульных тестах, мы думаем о каждом случае отдельно; под этим я подразумеваю, что мы думаем о каждом тесте как об уникальном и независимом. Представьте, что мы преподаватели в классе и что каждый вопрос на экзамене — это кейс; от первого вопроса, такого как: «Как тебя зовут?», до самых сложных, таких как: «Определи шаги, которые нужно предпринять в случае, если к тебе приблизится марсианин, накачанный кока-колой». Что касается вопросов, то первый из них простой; код / человек скажет свое имя. Но в последнем очень вероятно, что оба оцениваемых субъекта будут, мягко говоря, встревожены.
Модульные тесты, которые мы думаем как вопросы экзамена, тогда являются конкретными вопросами, и в большинстве случаев они должны быть атомарными, а затем интегрированы в одно выполнение; "Что ты? Что даешь? Как вы это даете? “
Мы должны знать, что выполнение модульных тестов — это 50% знания кода и 50% деструктивного творчества. Я говорю это потому, что мы должны рассмотреть все остальные способы, в которых система/код не должны работать, чтобы увидеть, как она реагирует, и, если необходимо, модифицировать код, чтобы адаптировать его для прохождения теста.
Преимущества:
- Измеренные ошибки: модульные тесты позволяют вам узнать, где ваша зона кода дает сбой или что мешает ее ожидаемому поведению, и, следовательно, помогает легче находить ошибки.
- Они являются частью документации кода.
- Упростите интеграцию: если интегрируемые части уже протестированы по отдельности, вам следует приложить усилия только к интеграции и интеграционным тестам.
- Они одобряют изменение: они являются отличным инструментом для разработчиков, чтобы положительно изменить код, улучшив его работу.
Характеристики
Когда меня спрашивают, как устроены модульные тесты, я обычно отвечаю, что это ACRI. Это означает:
Atomic и Automatable: небольшой и направленный на конкретную часть кода, которая не требует ручного вмешательства для ее выполнения.
Полныйполный: охватывает как можно большую часть кода.
Повторяемость: должен поддерживать подход DRY (не повторяйтесь) даже между проектами.
Независимая: хотя они могут выполняться в цепочках, каждая из них должна иметь возможность выполняться отдельно.
Большую часть времени, когда мы выполняем модульные тесты, мы анализируем исключения, которые они выдают. Работа модульного тестирования, помимо поиска правильного ответа, направлена на поиск несоответствий и ошибок, которые могут или должны работать в программе. Можно сказать, что модульные тесты на 70% состоят из поиска и контроля исключений системы или кода, что делает эти два поля теми, которым мы должны придавать большее значение. Много раз при выполнении модульных тестов в новом проекте исключений немного, и в подавляющем большинстве случаев они контролируются. Но по мере роста проекта и добавления новых строк, методов или классов появляется все больше и больше исключений. Следовательно, вы должны реорганизовать или отредактировать тесты, которые дают ошибки, и сравнить их с тем, что должно быть вашей основной целью.
Чтобы объяснить это лучше, давайте подумаем об алгоритме, который должен давать сумму двух целых чисел. Мы передаем в алгоритм два целых числа и, зная, что ответ правильный, значит, алгоритм сложения правильный. но что произойдет, если вы перегрузите его двумя строками или объектами числового типа, но не целочисленного типа? В любом из этих случаев он неизбежно потерпит неудачу, и возникает вопрос: должны ли мы перехватывать ошибку и позволять ей происходить или реорганизовать код так, чтобы он пытался преобразовать значения, присвоенные типу, который обрабатывается в методе? Любой из этих двух вариантов является допустимым. Тем не менее, жизненно важно изменить тест, а в случае кода необходим рефакторинг.
Тестовая модель для этого модуля в качестве примера будет выглядеть примерно так:
- Использовал метод с двумя целыми числами.
- Использовал метод с целым числом и строкой.
- Использовал метод с двумя строками.
- Использовал метод с двумя плавающими значениями.
- Использовал метод и не перегружал параметры.
В случаях 2 и 3 он должен отображать ошибку, но правильно, что код пытается преобразовать значения, которые входят в «строку», в числовые, если «строка» представляет собой число, такое как «3», а не 3.
. . .
Использование модульных тестов — это практика, которая помогает программистам создавать надежный и качественный код. По моему опыту, это отличный способ поэкспериментировать и повысить эффективность на языке, в котором у вас уже есть уровень выше среднего, расширяя свою зону комфорта в этом языке. Если они выполняются систематически, они помогают выявлять неожиданные конфликты кода, которые ускользают от нашего внимания, помогая работать в команде и повышая эффективность других методов, таких как GIT Workflow.
По вопросам о наших услугах по разработке и дизайну пишите нам по адресу [email protected].
Вы также можете посетить нас в Интернете: turpialdev.com или instagram, linkedin, facebook и twitter.
