Это НЕ модульное тестирование

Я был довольно тих в последние пару недель. В основном я был занят попытками изучения WPF, так что вы можете ожидать увидеть пару блогов на эту тему, как только я это освою. Первые мысли о WPF: это сложно .

Этот пост был вызван тем, что я посетил еще одну сессию оценки кода, где некоторые очень корпоративные кодеры демонстрируют свой ужасный код. Ведущий разработчик с гордостью сообщил, что весь код был охвачен модульными тестами. Посмотрев на код, я быстро понял, что не было найдено никаких модульных тестов. Тесты были фактически интеграционными тестами, реализованными с помощью NUnit .

Признаки того, что вы не проводите юнит-тестирование

Прежде чем перейти к основной проблеме, вот несколько признаков того, что вы на самом деле не проводите модульное тестирование (даже если вы используете NUnit или другую платформу модульного тестирования).

  1. У вас есть сценарии базы данных, которые необходимо запустить, прежде чем вы сможете запустить свои модульные тесты.
  2. В вашем тестовом проекте есть файл конфигурации.
  3. Модульные тесты могут выполняться только в специальной «тестовой среде» — разработчики не могут запускать их на своих машинах.
  4. Модульные тесты должны быть выполнены в указанном порядке.

Есть, вероятно, несколько других — это самые очевидные из тех, которые я мог придумать. Вот самый важный момент — то, что вы используете NUnit, не означает, что вы проводите модульное тестирование .

Нет четкого правила, что такое «Unit» в модульном тестировании, но в целом модульный тест будет тестировать один метод в одном классе . Если вы обращаетесь к базе данных в своих тестах, вы делаете интеграционные тесты. Если вы получаете доступ к любому внешнему компоненту в своих тестах, вы проводите интеграционные тесты.

Подумаешь?

Так какое же это имеет значение, если мы проводим интеграционные или юнит-тесты — это просто название, не так ли? На самом деле, это имеет значение — по 2 причинам.

  1. Если вы действительно проводите интеграционные тесты, значит, у вас нет юнит-тестов! Это, вероятно, указывает на то, что ваш код тесно связан, его сложно протестировать, и критические изменения не будут обнаружены. Это фактически означает, что мы вернулись на круги своя — мы не можем реорганизовать или повторно использовать код, не опасаясь появления ошибок. Ваши юнит-тесты не работают в качестве защитной сетки для внесения изменений в код.
  2. Если ваши модульные тесты сильно зависят от внешних компонентов, вы, вероятно, не проводите свои модульные тесты так часто, как следовало бы. В лучшем случае вы будете обнаруживать критические изменения только перед тем, как вносить изменения или во время сборки Continuous Integration (CI). В наихудшем сценарии (с которым я столкнулся в этом сценарии) вы обнаружите критические изменения только после развертывания в рабочей / тестовой среде.

так что нам делать?

Это не первый раз, когда я сталкиваюсь с этой проблемой. Я думаю, что наиболее распространенной причиной здесь является неопытность в модульном тестировании — код взломан старшим разработчиком, а младшим разработчикам поручено написать тесты для проверки функциональности. Это часто вызвано тем, что старшие разработчики не имеют опыта работы с юнит-тестами и считают это пустой тратой времени.

Не поймите меня неправильно — совместное использование модульных и интеграционных тестов — отличное решение. Единственная проблема заключается в том, что юнит-тесты вообще не проводятся. Имейте в виду, что существуют специальные платформы для реализации интеграционных тестов — Fitnesse , Selenium , WatiN и т. Д. Если вы собираетесь использовать инфраструктуру модульного тестирования для проведения интеграционных тестов, я бы четко разделил их — используя отдельные проекты или папки. хорошая идея

Интернет по оптике в Миассе AirNet

Author: admin

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *