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


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

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


7


источник


Ответы:


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

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

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


2



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

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

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

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

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


4



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

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

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


2



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


1



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

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

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

Продолжайте так же, работая над стеком приложений.

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


0