Определение, которому классы извлекли бы выгоду больше всего из поблочного тестирования?
Я работаю над проектом, где у нас есть только 13% покрытия кода с нашими модульными тестами. Я хотел бы придумать план улучшить это, но путем фокусировки сначала на областях, где увеличение покрытия принесет самое большое значение. Этот проект находится в C#, мы используем VS 2008 и 2008 TFS, и модульные тесты записаны с помощью MSTest.
Какую методологию я должен использовать для определения, какими классами мы должны заняться сначала? На какие метрики (код или использование) я должен смотреть (и как я могу получить те метрики, если это не очевидно)?
5 ответов
Для получения хорошей статистики и детерминированных запросов определенных методов вы можете определенно посмотреть NDepend: http://www.ndepend.com/
NDepend предоставляет язык запросов под названием CQL (язык запросов кода), который позволяет вы должны писать запросы к вашему коду, относящиеся к определенной статистике и статическому анализу.
Не существует верного способа определить, какие классы могут принести наибольшую пользу, однако, установив свои собственные пороговые значения в CQL, вы можете установить некоторые правила и соглашения.
Самая большая ценность модульного теста предназначена для обслуживания, чтобы гарантировать, что код по-прежнему работает после изменений.
Итак, сконцентрируйтесь на методах / классах, которые наиболее вероятно / наиболее часто изменяются.
Следующими по важности являются классы / методы с менее чем очевидной логикой. Модульные тесты сделают их менее уязвимыми, но при этом будут служить дополнительной «документацией» для API по контракту
Я бы рекомендовал добавлять модульные тесты ко всем классам, которых вы касаетесь, а не модифицировать существующие классы.
Большинство преимуществ модульного тестирования заключается в том, чтобы помочь программистам кодировать и гарантировать, что «Исправления» на самом деле ничего не сломают, если вы не добавляете код в новый раздел кода, который не каждый раз изменен, преимущества юнит-тесты начинают падать.
Вы также можете добавить модульные тесты к классам, на которые вы полагаетесь, если вам нечего делать.
Вы обязательно должны добавить тесты к новым функциям, которые вы добавляете, но вы, вероятно, также должны добавить тесты к существующим функциям, которые вы можете сломать.
Если вы делаете большой рефакторинг, сначала подумайте о том, чтобы охватить 80–100% этого раздела.
Разложите все компоненты по уровням. Каждый класс на данном уровне должен зависеть только от компонентов на более низком уровне. («Компонент» - это любая логическая группа из одного или нескольких классов.)
Сначала напишите модульные тесты для всех компонентов уровня 1. Обычно вам не нужны имитирующие фреймворки или другая подобная ерунда, потому что эти компоненты полагаются только на .NET Framework.
Как только уровень 1 будет пройден, начните с уровня 2. Если у вас хорошие тесты уровня 1, вам не нужно будет имитировать эти классы при написании тестов уровня 2.
Продолжайте аналогично, продвигаясь вверх по стеку приложений.
Совет: разбейте все компоненты на библиотеки DLL уровня. Таким образом вы можете гарантировать, что компоненты низкого уровня случайно не станут зависимыми от компонента более высокого уровня.
В целом модульные тесты - это инструмент для защиты от регрессии, и регрессия, скорее всего, произойдет в классах с самые зависимости. Вам не нужно выбирать, вы должны тестировать все классы, но если вам нужно, протестируйте классы, которые имеют наибольшее количество зависимостей в целом.