# Как мы тестируем анализаторы кода PVS\-Studio и CppCat

Всем привет\! Сегодня нам хотелось бы поделиться с вами как происходит тестирование наших анализаторов исходного кода С/С\+\+ CppCat и PVS\-Studio перед выпуском новых версий в свет\. Если вы не знакомы с этой линейкой продуктов, рекомендуется сделать это прямо сейчас\. Нет, нет, я вовсе не уговариваю вас обязательно установить эти замечательные продукты, просто вам будет гораздо легче и быстрее разобраться в смысле этой статьи :\-\)\.


> К сожалению, мы больше не развиваем и не поддерживаем проект CppCat\\\. Вы можете почитать \[здесь\]\(https://pvs\-studio\.ru/ru/blog/posts/0320/\) о причинах\\\.

Итак, на текущий день у нас есть два инструмента для анализа исходного кода в C/C\+\+ проектах\. Каждый из них позволяет указывать на потенциальные проблемы в коде\. Всем практикующим разработчикам давно известен тот факт, что всех ошибок избежать невозможно\. Способов успешно справляться с этой проблемой много, и каждая команда разработчиков выбирает тот, который наиболее подходит для текущего поддерживаемого и/или разрабатываемого проекта\. Естественно, у каждого подхода есть свои достоинства и недостатки — важно пойти по пути наименьшего сопротивления и выбрать наиболее подходящий их них\. Некоторые "покрывают" весь код тестами и буквально "тащат" за собой новый код вместе с новыми тестами, увеличивая время на разработку в разы\. Конечно, если на это есть деньги и время, это наиболее надежный вариант, но в реальной жизни это бывает крайне редко, потому что ни менеджерам проектов, ни заказчикам не хочется платить лишние деньги, а объяснять пользу от этого людям, которые далеки от программирования напоминает попытку кошки поладить с собакой\. Есть более разумный подход: [TDD](https://pvs-studio.ru/ru/blog/posts/cpp/a0080/) \(Test\-Driven Development \), в котором сначала пишутся тесты, а потом код\. Так можно быть уверенным в том, что мы хотим протестировать только то, что нам интересно\. Тот факт, что некоторые тесты никогда "не отваливаются" всегда наводит на мысль, что их слишком много\. Немного подумав, можно прийти к выводу, что для библиотек и собственных каркасов разработки наиболее подходят модульное тестирование, а для бизнес\-логики — интеграционное\. Это наиболее безболезненный и надежный подход для обеих сторон: разработчиков и заказчиков\.

К сожалению, так бывает не всегда и приходится искать совершенно другие варианты тестирования своих продуктов\. Так случается, когда есть очень много \(или хотя бы более одного\) компонентов, которые не укладываются в общую архитектуру и могут совершенно независимо существовать друг от друга\.  [CppCat](https://pvs-studio.ru/ru/cppcat/) и  [PVS\-Studio](https://pvs-studio.ru/ru/pvs-studio/) — как раз тот самый случай\. Конечно, мы можем запустить отладку для [Visual Studio experimental instance](https://pvs-studio.ru/ru/blog/posts/0165/), но подобный вариант не дает нам полной картины происходящего, другими словами — не подходит\.

Но тестировать нужно\! Поэтому у нас есть изолированное оконное приложение, которое позволяет убедится в полной корректности работы наших анализаторов \(Рисунок 1\)\.

Следует заметить, что это далеко не единственный метод тестирования, который мы используем, еще три года назад мы [писали](https://pvs-studio.ru/ru/blog/posts/a0047/), об используемых практиках при разработке анализатора\.

Некоторое время тестер работал только для [PVS\-Studio](https://pvs-studio.ru/ru/pvs-studio/)\. Он работал хорошо и нас это вполне устраивало\. С появлением [CppCat](https://pvs-studio.ru/ru/cppcat/) появилась необходимость в его расширении для работы в двух режимах\. Писать для этого отдельное Stand\-Alone приложение не стоит, поэтому нам пришлось интегрировать два режима работы в одном месте\. Следует заметить, что это не создание нового режима тестирования, а всего лишь модификация одного из многих способов, описанных в статье по ссылке выше\.

![0266_How_we_test_ru/image1.png](https://import.viva64.com/docx/blog/0266_How_we_test_ru/image1.png)

Рисунок 1 – Общий интерфейс тестера

Предлагаю немного погрузиться в ключевые моменты интерфейса программы для более полного понимания процесса:

![0266_How_we_test_ru/image2.png](https://import.viva64.com/docx/blog/0266_How_we_test_ru/image2.png)

Рисунок 2 – Текущие настройки запуска

Выпадающий список с текущими настройками для запуска тестера \(Рисунок 2\) позволяет нам указать, какие в данный момент режимы запуска мы хотим использовать\. Все они хранятся в обычных xml\-файлах\. Существует несколько режимов запуска: настройки, адаптированные для запуска тестера в Visual Studio 2010 IDE; настройки, которые используют только препроцессор и компилятор с Visual C\+\+; настройки по умолчанию, и т\. д\.

![0266_How_we_test_ru/image3.png](https://import.viva64.com/docx/blog/0266_How_we_test_ru/image3.png)

Рисунок 3 – Список проектов

Список проектов \(Рисунок 3\.\) позволяет нам выбрать типовые проекты для тестирования наших анализаторов\.

![0266_How_we_test_ru/image4.png](https://import.viva64.com/docx/blog/0266_How_we_test_ru/image4.png)

Рисунок 4 – Режим запуска

С режимом запуска \(Рисунок 4\) все понятно: он позволяет указать, какой анализатор мы хотим использовать в данных момент для прогона тестов\. 

![0266_How_we_test_ru/image5.png](https://import.viva64.com/docx/blog/0266_How_we_test_ru/image5.png)

Рисунок 5 – Хронология тестовых запусков

Хронология тестовых запусков \(Рисунок 5\) позволяет выбрать из выпадающего списка предыдущие тесты и посмотреть, что могло измениться на текущий момент\. 

![0266_How_we_test_ru/image6.png](https://import.viva64.com/docx/blog/0266_How_we_test_ru/image6.png)

Рисунок 6 – Параметры запуска

Параметры запуска \(Рисунок 6\) позволяют указать интегрированные среды разработки, в которых нужно запускать анализ\. Переключатель на панели Tasks позволяет указать, что мы хотим сделать: запустить тесты или сгенерировать эталоны \(Об эталонах мы поговорим чуть позже\)

Для того, чтобы убедится в корректной работе анализаторов, мы используем механизмы сравнения текущих полученных диагностик с эталонными\. Эталонные диагностики — это диагностики, которые используются для сравнения с текущими полученными\. Они хранятся в качестве обычных xml\-файлах\. Отличия, обнаруженные при сравнении — сигнал для нас, что тесты провалились и следует обратить внимание на последние правки кода, которые могли привести к неправильной работе\.

Из\-за того, что тестер изначально проектировался для PVS\-Studio и не был предназначен для расширения, возник целый ряд проблем при интеграции с другим плагином\. Не вдаваясь в детали, можно сказать, что [CppCat](https://pvs-studio.ru/ru/cppcat/) и [PVS\-Studio](https://pvs-studio.ru/ru/pvs-studio/) работают по\-разному\. Именно поэтому поддерживать существующий тестер становится с каждым разом все сложнее и сложнее\.

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