Инструмент анализа зависимостей - обновление тестовых случаев регрессии

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

Я сам большой поклонник Sonar, так как он у вас уже запущен и работает в вашей среде CI, это было бы моим предложением. Я не совсем уверен, что матрица цикла зависимостей Sonar еще не делает то, что вы хотите, или, скорее, то, что вы хотите в дополнение к этому.

Вы можете найти зависимости на уровне класса с помощью Classycle-Dependency Checker. И раздел - Проверка зависимости классов в руководстве может помочь в вашем случае. Однако обычно с помощью инструмента статического анализа мы анализируем либо базу исходного кода (например: Project-> src directory), либо тестовую базу кода (например, Project-> test directory), но не то и другое вместе. Но в вашем случае кажется, что вы тоже хотите выяснить зависимости между исходным и тестовым кодом. Таким образом, выполнение соответствующего инструмента анализа зависимостей путем предоставления входного пути в качестве родительского пути для src и test (например, корневой каталог проекта) может быть тем, что вам нужно (например: использование зависимостей выяснить -> если источник X изменяется, что это изменение влияет на зависимые классы в тестах).

Лучший инструмент, который вы можете найти для решения своей проблемы, - это на самом деле не инструмент, а практика. Я настоятельно рекомендую вам прочитать о разработке через тестирование (см. книгу Лассе Коскела) и «Спецификация на примере» (см. Книги Гойко Адзича, они великолепны).

Использование этих практик коренным образом изменит две вещи:

1. У вас будет тестовое покрытие, близкое к 100%
2. Тесты станут первоклассными гражданами и станут центральным элементом вашего кода.

Причина, по которой я считаю это актуальным для вашего вопроса, заключается в том, что ваш сценарий намекает на прямо противоположную роль тестов: люди будут вносить изменения в код, а затем подумают: «О, нет ... теперь мне нужно выяснить что я сломал в тех проклятых испытаниях ».

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

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

Прежде всего, необходимо рассмотреть в чем проблема с постоянным запуском всех тестов? Вот что CI означает. Если вы не можете запустить все свои модульные тесты за 15 минут и все ваши интеграционные / стресс-тесты за ночь, устраните любую проблему, которая вызывает это, возможно, купив какое-то оборудование.

В противном случае единственное, что может отследить потенциальную регрессию теста, - это анализ покрытия (например, http://www.eclemma.org/ < / а>). Учитывая даже базовый объектно-ориентированный дизайн, не говоря уже о внедрении зависимостей, статических пакетах или зависимостях классов, они в лучшем случае бессмысленны и, вероятно, активно вводят в заблуждение с точки зрения того, какие изменения могут привести к сбою тестов. И это игнорирует случай, когда проблема в том, что A должен звонить B, а не в этом случае. Однако перекрестные ссылки на измененные файлы с вызываемыми файлами, и если нет пересечения, возможно, не повторять тест, возможно, безопасно - оставшиеся сбои будут такими как некоторый код, добавляющий обработчик событий там, где его раньше не было.

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

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

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

Есть несколько практических проблем с выполнением этой работы.

Во-первых, часто бывает трудно понять, как инструменты тестового покрытия записывают эти данные о местоположении. Во-вторых, вы должны получить механизм тестирования, чтобы фиксировать его на каждой тестовой основе; это может быть неудобно для организации, и / или данные о покрытии могут быть неудобными для извлечения и хранения. В-третьих, вам необходимо вычислить пересечение «кода, измененного» с «кодом, покрытым» тестом; абстрактно это в значительной степени проблема пересечения больших битовых векторов. Наконец, захват «измененного кода» немного сложен, потому что иногда код перемещается; если было проверено местоположение 100 в файле, и строка перемещается в файле, вы можете не получить сопоставимые данные о местоположении. Это приведет к ложным срабатываниям и ложным отрицаниям.

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

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

Некоторые инструменты, которые могут помочь. Обратите внимание, что не все они интегрируются с CI.

iPlasma - отличный инструмент.

CodePro - это подключаемый модуль Eclipse, который помогает в обнаружении кода и проблемы проектирования (например, дублированный код, классы, нарушающие инкапсуляцию, или методы, помещенные в неправильный класс). (Теперь приобретено Google)

Relief - это инструмент, визуализирующий следующие параметры проектов Java: размер пакета, то есть количество классов и интерфейсов в нем. содержит тип визуализируемого элемента (пакеты и классы представлены в виде блоков, интерфейсы, а поля типов - в виде сфер). насколько тяжелый используется предмет (представлен как сила тяжести, то есть расстояние до центра); количество зависимостей (представлено как глубина).

Stan4j - это коммерческий инструмент, который стоит пару сотен долларов. Он нацелен только на проекты Java, очень близок к (или немного лучше отчетов, чем? Не уверен) Sonar. Имеет хорошую интеграцию с Eclipse.

Анализ зависимостей Intellij

Насколько я понял из вашей проблемы, вам необходимо отслеживать две объектно-ориентированные метрики - Эфферентная связь (Ca) и Эфферентная связь (Ce) . Благодаря этому вы можете сузить круг до требуемых пакетов. Вы можете изучить возможность написания плагина eclipse, который при каждой сборке может выделять необходимые классы на основе показателей Ca, Ce.