Это отрывок из электронной книги «Единичное тестирование » Марка Клифтона, любезно предоставленный Syncfusion.
Обычная мантра, которую мы слышим о любой методологии программного обеспечения, заключается в том, что она повышает удобство использования и качество, сокращает время разработки и тестирования и выводит продукт на рынок быстрее и с меньшим количеством ошибок. Это высокие цели, но мне еще предстоит увидеть методологию, которая поставила бы Грааль разработки программного обеспечения.
В конечном счете, основная причина написания модульных тестов — доказать правильность, и это происходит, только если вы хорошо пишете модульные тесты . Модульные тесты сами по себе не улучшат удобство использования или качество вашего продукта. Вы все еще можете испортить приложение, независимо от того, доказано ли оно правильным или нет — и это, безусловно, не гарантирует сокращение времени разработки и тестирования (подробнее об этом позже) или вывод вашего продукта на рынок раньше.
Итак, давайте будем ясны и реальны с самого начала: модульное тестирование может использоваться для проверки правильности, и любой побочный эффект , возникающий в процессе разработки, должен быть сбалансирован с усилиями написания и поддержки полезных модульных тестов.
Измерение правильности
Хорошо написанные модульные тесты обеспечат вам ощутимую степень уверенности в том, что множество методов, входящих в ваше приложение, будут работать правильно. Самый простой способ объективно выполнить это измерение — это тест покрытия: какой процент методов в вашем приложении имеет написанные для них модульные тесты? Хотя этот вопрос напрямую не затрагивает вопрос о том, должен ли метод рассматриваться как единое целое (будет обсуждаться позже) или имеют ли смысл тесты, тем не менее это измерение, которое вы можете выполнить в любое время и которое можно использовать в качестве эталона для правильности ваше приложение.
Модульное тестирование — это итеративный процесс — всегда будут ошибки, которые пропускаются при модульном тестировании. Тем не менее, количество ошибок, обнаруженных с течением времени, а также количество нерешенных и решенных проблем предоставляет значимую информацию о состоянии вашего приложения. Хотя невозможно сказать: «Благодаря модульному тестированию число ошибок было уменьшено на 50 процентов», можно измерить, сколько ошибок в вашем приложении из-за неполного охвата модульных тестов. При написании модульных тестов для проверки проблемы и исправления вы также можете измерить количество написанных вами модульных тестов по сравнению с зарегистрированными ошибками по сравнению с общим количеством модульных тестов.
Все эти тесты обеспечивают определенную степень объективности процесса разработки. Поэтому одним из преимуществ модульного тестирования является то, что оно предоставляет всем, от разработчиков до менеджеров, объективную информацию, которая может быть возвращена в процесс разработки для улучшения этого процесса.
Повторение, Повторение, Повторение
Другим преимуществом является повторяемость, также известная как регрессионное тестирование. По мере развития приложения мы хотим убедиться, что существующий рабочий код не поврежден. Путем написания модульных тестов для методов по мере их написания и добавления модульных тестов для ошибок, когда они сообщаются, все они могут автоматически проверяться при добавлении нового кода или изменении существующего кода. Модульные тесты становятся значительным инструментом сокращения времени, когда дело доходит до проверки того, продолжает ли приложение вести себя правильно после незначительного или значительного изменения кода. Хотя модульное тестирование не заменяет юзабилити-тестирование, тестирование производительности, нагрузочное тестирование и т. Д., Оно определенно помогает избежать затрат времени на общий вопрос: «Это работало раньше; почему нет сейчас?
Покрытие кода
Легко проверить, что метод работает правильно, когда все процессы в методе выполняются линейно. Однако, как только вы добавляете оператор if или оператор switch , вы создаете цикломатическую сложность , которая является причудливым способом сказать, что ваш код теперь имеет несколько путей выполнения. Наиболее полезные модульные тесты — это те, которые проверяют каждую ветвь кода, которая встречается в вашем методе. Написание такого рода модульных тестов может быть кропотливым, но оно того стоит, поскольку оно гарантирует, что по крайней мере каждая ветвь кода была выполнена, что не может происходить во время приемочного тестирования, юзабилити-тестирования или другого тестирования, которое обеспечивает контроль качества. отдел (если есть) выполняет.
В этой серии статей мы рассмотрим различные стратегии и советы о том, как выполнить эффективное модульное тестирование.