Определение того, какие классы больше всего выиграют от модульного тестирования?


Я работаю над проектом, в котором мы имеем только 13% покрытия кода с помощью наших модульных тестов. Я хотел бы разработать план по улучшению этого положения, но сначала сосредоточусь на тех областях, где увеличение охвата принесет наибольшую пользу. Этот проект находится в C#, мы используем VS 2008 и TFS 2008, а модульные тесты out написаны с использованием MSTest.

Какую методологию я должен использовать, чтобы определить, какие классы мы должны рассмотреть в первую очередь? Какие метрики (код или использование) я должен рассматривать (и как могу ли я получить эти показатели, если это не очевидно)?

5   7   2010-03-18 00:04:44

5 ответов:

Для получения хорошей статистики и детерминированного запроса определенных методов вы можете определенно посмотреть на NDepend: http://www.ndepend.com/

NDepend предоставляет язык запросов CQL (Code Query Language), который позволяет писать запросы к вашему коду, относящиеся к определенной статистике и статическому анализу.

Нет истинного способа определить, какие классы могут принести наибольшую пользу, однако, установив свои собственные пороговые значения в CQL, вы можете установить некоторые правила и конвенции.

Я бы рекомендовал добавлять модульные тесты ко всем классам, к которым вы прикасаетесь, а не перестраивать существующие классы.

Большинство преимуществ модульного тестирования заключается в том, что оно помогает программистам писать код и гарантирует, что "исправления" на самом деле ничего не ломают, если вы не добавляете код в новый раздел кода, который не каждый раз изменяется, преимущества модульных тестов начинают уменьшаться.

Вы также можете добавить модульные тесты в классы, на которые вы полагаетесь, если вам нечем заняться.

Ты абсолютно необходимо добавить тесты к новой функциональности, которую вы добавляете, но вы, вероятно, также должны добавить тесты к существующей функциональности, которую вы можете нарушить.

Если вы делаете большой рефактор, рассмотрите возможность получения 80-100% покрытия на этом разделе В первую очередь.

Самое большое значение модульного теста - это обслуживание, чтобы гарантировать, что код все еще работает после изменений.

Итак, сосредоточьтесь на методах / классах, которые наиболее вероятно / наиболее часто изменяются.

Следующими по важности являются классы / методы с менее чем очевидной логикой. Модульные тесты сделают их менее хрупкими, служа дополнительной "документацией" для их контрактного API

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

Распределите все компоненты по уровням. Каждый класс на данном уровне должен зависеть только от компонентов на более низком уровне. ("Компонент" - это любая логическая группа из одного или нескольких классов.)

Сначала напишите модульные тесты для всех компонентов уровня 1. Обычно вам не нужны насмешливые фреймворки или другая подобная ерунда, потому что эти компоненты полагаются только на .NET Framework.

Как только уровень 1 будет завершен, начните с уровня 2. Если тесты 1-го уровня хороши, Вам не нужно будет издеваться над ними занятия, когда вы пишете тесты 2-го уровня.

Продолжайте в том же духе, продвигаясь вверх по стеку приложений.

Совет: разбейте все компоненты на библиотеки DLL определенного уровня. Таким образом, вы можете гарантировать, что компоненты низкого уровня не будут случайно зависеть от компонента более высокого уровня.