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

Ouédraogo W. C., Li Y., Dang X., Zhou X., Koyuncu A., Klein J., Lo D., Bissyandé T. F. Rethinking Cognitive Complexity for Unit Tests: Toward a Readability-Aware Metric Grounded in Developer Perception : preprint. — arXiv:2506.06764v2 [cs.SE], 22 Aug 2025. — DOI: 10.48550/arXiv.2506.06764.

Аннотация

Автоматически генерируемые модульные тесты — из поисковых инструментов вроде EvoSuite или из LLM — сильно различаются по структуре и читаемости. Тем не менее большинство оценок опирается на метрики, такие как цикломатическая сложность и когнитивная сложность, изначально разработанные для функционального кода, а не для тестов. Недавние работы показали, что метрика Cognitive Complexity от SonarSource присваивает почти нулевые значения тестам, сгенерированным LLM, однако её поведение на тестах EvoSuite и применимость к специфическим для тестов конструкциям остаются неизученными. Мы предлагаем CCTR — «тест-ориентированную» метрику когнитивной сложности для модульных тестов. CCTR интегрирует структурные и семантические признаки — плотность ассертов, роли аннотаций, шаблоны композиции тестов — измерения, игнорируемые традиционными моделями сложности, но критически важные для понимания тестового кода. Мы оцениваем 15 750 тестовых наборов, сгенерированных EvoSuite, GPT-4o и Mistral Large-1024, по 350 классам из Defects4J и SF110. Результаты показывают, что CCTR эффективно различает структурированные и фрагментированные тестовые наборы, выдавая интерпретируемые оценки, которые лучше отражают воспринимаемые разработчиками усилия. Соединяя структурный анализ и читаемость тестов, CCTR закладывает основу для более надёжной оценки и улучшения сгенерированных тестов. Для воспроизводимости мы публикуем все данные, промпты и скрипты оценки.

I. Введение

По мере эволюции автоматизации тестирования традиционные инструменты, такие как EvoSuite [1], всё чаще дополняются подходами на основе больших языковых моделей (LLM) [2], [3], [4], [5], [6], [7], [8], что позволяет масштабировать генерацию модульных тестов для широкого спектра программных систем. Однако недавние исследования сообщают, что лишь 40–70% модульных тестов, сгенерированных LLM, успешно компилируются без ручных вмешательств [7], [3], [2], [8]. Даже будучи синтаксически корректными, их структурное качество и читаемость остаются непоследовательными и трудными для оценки.

Это исследование финансировалось Люксембургским национальным фондом исследований (FNR), грант AFR PhD bilateral, номер проекта 17185670. Ответственный автор — Yinghua Li.

Это поднимает вопрос о том, как осмысленно оценивать сложность и сопровождаемость сгенерированного тестового кода — область, где существующие метрики дают ограниченные ориентиры. Традиционные статические метрики сложности, такие как цикломатическая сложность [9] и Cognitive Complexity от SonarSource [10], изначально предназначены для оценки функциональной логики, а не тестового кода. Хотя недавние работы [11], [12], [3], [6], [8] последовательно фиксируют очень низкие значения когнитивной сложности для тестов, сгенерированных LLM, ни одна из них не оценивала эту метрику на наборах тестов EvoSuite и не проверяла её способность отражать структурную и семантическую сложность тестового кода — что вызывает сомнения в пригодности этих метрик для оценки качества тестов.

Параллельно исследования читаемости тестов [13], [14] подчёркивают важность ясности ассертов, выразительных имён и соблюдения структурных соглашений. В частности, широко принят шаблон Arrange–Act–Assert (AAA), повышающий читаемость тестов за счёт чёткого разделения этапов подготовки, выполнения и проверки. Машинно-обученная модель читаемости, предложенная Scalabrino и соавт. [15] и позднее валидированная Sergeyuk и соавт. [16], аппроксимирует человеческие суждения о читаемости на основе текстовых признаков. Однако она фокусируется главным образом на поверхностных атрибутах — ясности идентификаторов и форматировании — и не учитывает более глубокие структурные аспекты, такие как фрагментация, плотность ассертов или сложность потока управления. Это оставляет критический пробел в количественной оценке структуры и сопровождаемости тестов.

Мы предлагаем CCTR — «тест-ориентированную» метрику когнитивной сложности, специально адаптированную для модульных тестов. CCTR интегрирует структурные и семантические элементы — использование ассертов, роли аннотаций и шаблоны композиции тестов — в лёгкую и интерпретируемую оценку, которая отражает как синтаксическую структуру, так и когнитивные усилия, требуемые для понимания наборов тестов. Для оценки эффективности мы анализируем 15 750 наборов тестов, сгенерированных EvoSuite, GPT-4o и Mistral Large, по наборам Defects4J [17] и SF110 [18]. Результаты показывают, что CCTR эффективно различает фрагментированные автогенерируемые тесты и хорошо структурированный код, лучше согласуясь с аспектами, ценимыми разработчиками — такими как ясность ассертов, структура тестов и семантический замысел, — по сравнению с Cognitive Complexity от SonarSource [10], и выступая осмысленным прокси-показателем сопровождаемости тестов.

Вклад. В данной работе представлены:

• критический анализ ограничений метрики Cognitive Complexity при применении к тестовому коду;
• новая метрика CCTR, предназначенная для количественной оценки структурной и семантической сложности модульных тестов;
• крупномасштабная эмпирическая оценка CCTR на 15,750 наборах тестов;
• подтверждение того, что CCTR точнее отражает аспекты читаемости тестов по сравнению с существующими метриками;
• открытый набор данных из 15,750 сгенерированных наборов тестов по 350 Java-классам, включающий оценки CCTR, шаблоны промптов и скрипты для оценки: https://github.com/Cwendkuuni/CCTR

Структура статьи. Дальнейшее изложение организовано следующим образом: в Разделе II обосновывается необходимость специализированной метрики для тестов на конкретных примерах; Раздел III описывает экспериментальную установку и датасет; Раздел IV обсуждает недостатки существующих метрик сложности; в Разделе V представляется и оценивается CCTR; Раздел VI содержит обсуждение результатов и ограничений; Раздел VII — обзор связанных работ; Раздел VIII — заключение.

II. Мотивирующий пример

Чтобы обосновать необходимость метрики сложности, ориентированной на тесты, мы приводим три примера: два реальных набора тестов для класса CommandLine из дефекта Cli-1 (Defects4J) и один синтетический случай по управлению потоком исполнения. Полные версии доступны в пакете для воспроизведения. Мы используем реализованную в PMD [19] версию Cognitive Complexity, основанную на спецификации SonarSource [10], которая «взвешивает» конструкции управления потоком и вложенность для оценки умственных усилий.

A. Пример 1: глубоко вложённый, но тривиальный код

						public class ExampleTest {
							public void testExample() {
								if (condition) {
									for (int i = 0; i < 10; i++) {
										while (anotherCondition) {
											// nested logic
										}
									}
								}
							}
						}
					

Листинг 1 демонстрирует структурную вложенность при минимальной логике. PMD присваивает ему Cognitive Complexity, равную 12.

B. Пример 2: набор тестов, сгенерированный LLM

						@Test
						public void testGetOptionValueWithDefaultValue() {
							assertEquals("default", commandLine.getOptionValue("test", "default"));
						}
					

Листинг 2 показывает часть набора из 12 методов, сгенерированного GPT-4o. Несмотря на осмысленные имена, согласованную структуру и аннотации, понимание всё же требует усилий из-за множества методов, логики ассертов и вариативности параметров. Тем не менее PMD присваивает ему когнитивную сложность 0, не учитывая эту умеренную структурную и семантическую нагрузку.

C. Пример 3: набор тестов, сгенерированный EvoSuite

						@Test(timeout = 4000)
						public void test02() throws Throwable {
							CommandLine commandLine0 = new CommandLine();
							Option option0 = new Option("", "\"Jd", true, "D1,L");
							option0.addValue("org.apache.commons.cli.CommandLine");
							commandLine0.addOption(option0);
							String string0 = commandLine0.getOptionValue("--", null);
							assertNotNull(string0);
							assertEquals("org.apache.commons.cli.CommandLine", string0);
						}
					

Листинг 3 — часть набора из 17 методов, сгенерированного EvoSuite. Он отличается неинформативными именами и отсутствием структурной ясности или семантической группировки. Тем не менее его показатель Cognitive Complexity по PMD — 0.

Как показывают эти примеры, ориентированный на поток управления подход не фиксирует ключевые структурные и семантические аспекты модульных тестов. Несмотря на явные различия в читаемости, структуре и замысле разработчика, все три случая получают почти идентичные оценки — что подчёркивает несоответствие между предпосылками SonarSource и реальными умственными усилиями, необходимыми для понимания тестового кода.

D. Резюме

В таб. 1 суммируются оценки когнитивной сложности PMD для трёх примеров. Чтобы лучше показать расхождение между оценками PMD и интуитивно воспринимаемыми усилиями на понимание, мы добавляем метку «воспринимаемой сложности», основанной на структурной и семантической ясности. В то время как тривиальный пример с вложенностью получает ненулевую оценку, более когнитивно нагруженные наборы тестов оцениваются как ноль — что демонстрирует критическое несоответствие разработческой интуиции.

Эти результаты подчёркивают критический разрыв: хотя PMD улавливает структурную вложенность, он не отражает воспринимаемую человеком сложность реальных тестовых наборов — особенно тех, где много логики ассертирования, используется мокирование или присутствует неоднозначная структура. Это мотивирует ввод специализированной для тестов метрики когнитивной сложности в Разделе V.

III. Эмпирические наблюдения в масштабе

A. Набор данных и настройка генерации тестов

Чтобы оценить CCTR, мы провели крупномасштабное исследование, используя два признанных корпуса Java-кода: Defects4J [17] и SF110 [18]. Эти бенчмарки предоставляют разнообразные реальные классы с различной сложностью, что создаёт надёжную основу для оценки как традиционно сгенерированных, так и LLM-сгенерированных тестовых наборов.

Состав набора данных. Мы выбрали 15 проектов из Defects4J (147 классов) и 69 проектов из SF110 (203 класса) — всего 350 классов из 84 проектов. Сводные характеристики приведены в таб. 2.

Генерация тестов. Мы генерировали модульные тесты для каждого класса тремя способами: EvoSuite [1] с лимитом времени 3 минуты и алгоритмом поиска DynaMOSA [18], GPT-4o [20] и Mistral Large-2407 c zero-shot-промптингом. Чтобы снизить случайность в выводах LLM, мы установили температуру 0.1 и оставили top-p по умолчанию. Каждый инструмент/модель запускался по 15 раз на класс, что дало 2 205 тестовых наборов на модель для Defects4J и 3 045 на модель для SF110. В сумме мы получили 10 500 тестовых наборов от LLM и 5 250 от EvoSuite, итого 15 750 тестовых наборов.

Характеристики тестов. Таб. 3 показывает усреднённые метрики по всем сгенерированным тестам. EvoSuite создавал более длинные тестовые классы с большим количеством методов и более высоким количеством токенов; LLM-сгенерированные тесты были компактнее, но более семантически выразительны. Доли успешной компиляции составили 100% для EvoSuite и ниже для LLM из-за эпизодических синтаксических ошибок или некорректного использования API.

B. Анализ сложности кода и читаемости

Мы представляем крупномасштабный сравнительный анализ наборов модульных тестов, сгенерированных LLM и EvoSuite, с трёх взаимодополняющих точек зрения: цикломатическая сложность, когнитивная сложность и автоматические оценки читаемости по Scalabrino и соавт. [15].

Цикломатическая сложность. Цикломатическая сложность [9] оценивает число линейно независимых путей и аппроксимирует «плотность» потока управления. Как показано в таб. 4a, наборы тестов, сгенерированные LLM и EvoSuite, демонстрируют существенную сложность потока управления, особенно в SF110, что подтверждает: сгенерированный тестовый код содержит нетривиальные пути исполнения и далёк от структурной простоты.

Читаемость. Чтобы масштабно аппроксимировать воспринимаемую читаемость, мы используем модель Scalabrino и соавт. [15], объединяющую 104 структурных, текстовых и визуальных признака, обученных на аннотированном Java-коде, включая JUnit-тесты. Как показано в таб. 4b, модель стабильно считает тесты, сгенерированные LLM, более читаемыми, чем тесты из EvoSuite. Sergeyuk и соавт. [16] показали, что эта модель лучше всего согласуется с человеческими оценками среди известных альтернатив [21], [22], [23], [24], [25].

Когнитивная сложность. Мы используем реализацию Cognitive Complexity из PMD [10], которая штрафует вложенные конструкции управления, логические операторы и элементы, нарушающие поток. Как видно из таб. 5, метрика выдаёт крайне низкие значения — часто нулевые — для LLM-тестов и умеренные оценки для EvoSuite, несмотря на сильную фрагментированность тестовых классов. Это указывает, что Cognitive Complexity упускает многие характеристики, повышающие когнитические усилия при понимании тестов, включая логику ассертирования, мокирование и тест-специфичные идиомы дизайна.

Вывод. Каждая перспектива фиксирует свой аспект: «плотность» потока управления (Cyclomatic), воспринимаемую читаемость (Scalabrino) и усилия, связанные с вложенной логикой (Cognitive Complexity). Цикломатическая сложность и модель Scalabrino эффективно работают в своих областях, но Cognitive Complexity от Sonar — несмотря на растущее использование в оценке качества — разработана для функционального кода, а не для тестов. Наши результаты показывают, что она не отражает структурные и семантические усилия, требуемые для понимания тестов, игнорируя тест-специфичные паттерны вроде логики ассертирования, конструкций мокирования и ролей на основе аннотаций. Этот разрыв мотивирует необходимость специализированной метрики когнитивной сложности, учитывающей уникальные особенности тестового кода.

IV. Ограничения Cognitive Complexity для тестов

Хотя метрика Cognitive Complexity от SonarSource [10] широко применяется для оценки понятности исходного кода, изначально она была спроектирована для измерения умственных усилий, необходимых для понимания функциональной логики, а не модульных тестов. В этом разделе мы выделяем три ключевых ограничения при её применении к тестовому коду.

A. Не рассчитана на конструкции модульных тестов

Cognitive Complexity штрафует вложенные конструкции управления (if, for, while), логические операторы и разрывы потока (break, return) — конструкции, характерные для «бизнес-логики», но менее типичные для хорошо написанных модульных тестов. Напротив, элементы, сильно влияющие на читаемость и структуру тестов — ассерты, вызовы моков и аннотации вроде @Test или @ParameterizedTest — полностью игнорируются. В итоге методы, интенсивно использующие «тест-специфичные» конструкции (ассерты, моки, аннотации), могут по-прежнему получать нулевые оценки сложности, что подрывает применимость метрики для оценки сгенерированных тестов или сравнения наборов между инструментами.

B. Эмпирические наблюдения по сгенерированным тестам

Мы приводим наблюдения из анализа 15 750 наборов тестов, сгенерированных EvoSuite, GPT-4o и Mistral Large (см. Разделы II и III). Несмотря на заметные различия в структурном качестве и читаемости, реализация Cognitive Complexity в PMD присваивает нулевые оценки более чем 99% методов, созданных LLM, и лишь умеренные — результатам EvoSuite. Как показано в Разделе II, даже «учебный» глубоко вложенный пример получил 12 баллов, тогда как реальные тестовые наборы с насыщенной семантикой и нетривиальными асертами часто имели ноль. Это подчёркивает ключевое ограничение: метрика не улавливает структурные и когнитивные усилия, присущие тестовому коду, особенно для тестов, сгенерированных современными LLM.

C. Несоответствие измеряемым аспектам читаемости тестов

Недавние исследования показывают, что читаемость тестов выходит за рамки потока управления. Winkler и др. [13] отмечают, что разработчики приоритезируют чёткую структуру (шаблон AAA), осмысленные имена, логику ассертов и ясную подготовку окружения. Аналогично, Daka и др. [14] и Biagiola и др. [11] показывают, что воспринимаемое качество тестов сильнее связано с именованием, структурой и намерением ассертов, чем с вложенностью или ветвлениями. Ни один из этих аспектов Cognitive Complexity не покрывает. Растущее использование этой метрики для оценки тестов, сгенерированных LLM [11], [12], не имеет достаточного обоснования. «Тест-специфичная» метрика сложности должна отражать когнитивные усилия, связанные с особыми конструкциями тестов, а не только с потоком управл

Эти ограничения мотивируют разработку новой метрики, учитывающей реальные структурные и семантические особенности тестовых наборов.

V. К "тест-специфичной" когнитивной сложности

Мы предлагаем CCTR (Cognitive Complexity for Test Readability — «когнитивная сложность с учётом читаемости тестов»), «тест-специфичную» метрику, предназначенную для количественной оценки структурных и семантических усилий при понимании тестов. CCTR устраняет ограничения существующих метрик, фиксируя конструкции, которые разработчики реально обрабатывают, читая тесты — ассерты, паттерны мокирования и аннотации — при этом сохраняя чувствительность к потоку управления.

A. Эмпирическая мотивация

CCTR опирается на ориентированную на разработчиков эмпирическую модель Winkler и др. [13], которая выделяет три основные размерности понимания тестов: (1) структура теста (напр., чёткость AAA, отступы), (2) семантика именования и выражений (напр., намерение ассертов, ясность переменных) и (3) логика и цель теста (напр., релевантность подготовки, целевая проверка). Каждый компонент CCTR спроектирован так, чтобы отражать одну или несколько из этих размерностей

В частности, включение аннотаций вдохновлено результатами Guerra и др. [26], показавших, что аннотации вроде @Test и @NotNull улучшают читаемость и передают роли в тестах — но при этом предупреждавших о рисках чрезмерного использования. Соответственно, CCTR назначает веса с балансом между информативностью и вкладом в сложность.

B. Определение CCTR

Мы определяем CCTR как:

\[ \mathrm{CCTR} = \alpha \cdot N + \beta \cdot A + \gamma \cdot M + \delta \cdot T \tag{1} \]

Здесь N обозначает сложность вложенности потока управления (в соответствии с исходным определением SonarSource). Термин A соответствует числу выражений assert или вызовов fail() в тестовом методе. Компонент M учитывает количество конструкций для мокирования, таких как вызовы mock(), verify() или when(). Наконец, T отражает «сигнализацию» на основе аннотаций: ему присваивается значение +1 за каждое появление распространённых тестовых аннотаций, таких как @Test, @BeforeEach и @AfterEach, и значение +2 при наличии более специализированных аннотаций, например @ParameterizedTest.

ы используем начальные веса:

\[\alpha = \beta = \gamma = \delta = 1.0\]

Такое равное взвешивание соответствует нашей цели — простоте и интерпретируемости — и согласуется с эмпирическими работами, предполагающими сопоставимый вклад этих факторов в понимание тестов. Наше отношение к аннотациям также опирается на результаты Guerra и др. [26], показавших, что аннотации вроде @Test и @NotNull улучшают структурную ясность и обозначение намерений (особенно при определении ролей тестов или правил валидации). Однако они предостерегают от избыточного использования и неоднозначности. Чтобы сбалансировать информативность и «раздувание» оценки, CCTR назначает умеренные фиксированные веса типам аннотаций. Настройка этих весов — задача для будущих исследований, ориентированных на крупномасштабные опросы разработчиков.

C. Оценка и наблюдения

Чтобы оценить CCTR, мы вычислили значения метрики на двух бенчмарках (Defects4J, SF110) и для трёх стратегий генерации тестов: GPT-4o, Mistral Large и EvoSuite.

Результаты. Из таб. 6 вытекает несколько наблюдений. Наборы тестов, сгенерированные LLM (GPT-4o, Mistral), показывают умеренную сложность (средние значения 26–30), что согласуется с их структурированным, но лаконичным стилем. Напротив, тесты EvoSuite получают существенно более высокие оценки из-за фрагментированной структуры, большого числа методов и высокой «плотности» ассертирования. CCTR также различает тестовые наборы, которые метрика когнитивной сложности SonarSource не отделяет, — фиксируя различия как на уровне генератора, так и на уровне датасета. Наконец, несмотря на вариативность LOC и числа токенов, CCTR устойчиво «масштабируется» между инструментами и наборами данных. Эти результаты показывают, что CCTR лучше отражает усилия на понимание тестов, согласуясь с принципами, ориентированными на разработчиков, и со структурными различиями.

D. Иллюстрация Чтобы показать, как CCTR улавливает структурные и семантические различия, мы возвращаемся к трём примерам из Раздела II. В таб. 7 приведены как оценки PMD, так и CCTR, демонстрируя, что традиционные метрики не отражают различия в требуемых усилиях на понимание.

Каждый тестовый класс представляет свой стиль и уровень структурной ясности. «Вложенный тривиальный код» (Листинг 1), будучи семантически простым, содержит глубокую вложенность потока управления и даёт умеренную оценку CCTR, равную 12, что отражает структурную сложность. «Набор тестов, сгенерированный LLM» (Листинг 2) получает ту же оценку, но по иным причинам: краткие методы, согласованные ассерты, понятные имена и информативные аннотации. Напротив, «набор тестов, сгенерированный EvoSuite» (рис. 3) содержит 17 фрагментированных методов с синтетическими именами и избыточными асертами, в результате чего CCTR значительно выше — 35, что указывает на возросшие усилия на понимание.

Эти примеры показывают, что CCTR даёт содержательные, различимые оценки на уровне класса, отражая структурные различия между стилями тестов. В сочетании с таб. 6 это иллюстрирует применимость метрики как к частным случаям, так и к крупномасштабным бенчмаркам.

VI. Обсуждение и направления дальнейшей работы

Практические выводы. CCTR предлагает специализированный для тестов взгляд на оценку там, где критична читаемость, — помогает в рефакторинге, проектировании и автоматическом ревью. Интегрируя ассерты, мокирование и аннотации, метрика даёт когнитивно обоснованный прокси-показатель сопровождаемости. CCTR также масштабируется на автогенерируемые тесты, позволяя пакетно оценивать качество синтеза.

Переосмысление прежних метрик. Наши результаты показывают, что существующие структурные метрики — цикломатическая сложность и метрика когнитивной сложности — не отражают семантические и структурные измерения, центральные для дизайна модульных тестов. Это объясняет, почему в прошлых работах [11], [12] прибегали к обходным путям (CodeBLEU [27] или косинусное сходство) для валидации рефакторинга, несмотря на слабое теоретическое основание. CCTR предлагает принципиально обоснованную альтернативу.

Ограничения. Как и другие статические метрики, CCTR не покрывает все аспекты качества тестов — она не измеряет поведенческую корректность, «флаки» и способность обнаруживать дефекты. Её фиксированные веса, хотя и эмпирически мотивированы, могут не обобщаться на все стили тестов. Тем не менее CCTR дополняет динамические анализы и другие метрики в рамках более широкой оценки. Кросс-доменные и кросс-языковые проверки остаются задачами будущей работы.

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

VII. Связанные работы

Метрики сложности кода. Цикломатическая сложность Маккейба [

Модели читаемости. Существует ряд моделей, оценивающих читаемость по лексическим, синтаксическим или визуальным признакам, включая работы Buse и Weimer [21], [22], Dorn и др. [24], Posnett и др. [23]. Scalabrino и др. [15] предложили модель из 104 признаков, позднее валидированную Sergeyuk и др. [16]. Для общего кода они эффективны, но делают упор на поверхностные сигналы и упускают структурные/когнитивные особенности, критичные для тестов. CCTR закрывает этот разрыв метрикой, нацеленной на тест-специфичную понятность.

Оценка сгенерированных тестов. С появлением генерации кода LLM возникли новые методы оценки качества тестов. Biagiola и др. [11] и Deljouyi и др. [12] применяли CodeBLEU и семантическое сходство для выявления галлюцинаций или проверки корректности рефакторинга, но эти меры слабо связаны с понятностью тестов. Наша работа вводит тест-специфичную метрику сложности, фиксирующую структурные сигналы — ассерты, аннотации и логику теста — которые игнорируются существующими синтаксическими метриками и эмбеддинговыми оценками.

VIII. Заключение и дальнейшая работа

Мы представили CCTR — метрику сложности, учитывающую специфику тестов, и предназначенную для фиксации структурных и семантических элементов, критичных для понимания модульных тестов (плотность ассертов, конструкции мокирования, семантика аннотаций). Опираясь на эмпирические исследования читаемости тестов, CCTR дополняет традиционные метрики, ближе согласуясь с разработческой интуицией. Наша оценка на 15 750 наборах тестов показывает, что CCTR эффективно различает стили генерации и выдаёт оценки, отражающие структурные усилия. Соединяя анализ сложности с тест-специфичной читаемостью, CCTR открывает новые возможности для оценки, рефакторинга и улучшения модульных тестов. Дальнейшая работа будет сосредоточена на валидировании с участием людей, адаптивном взвешивании и интеграции в конвейеры генерации тестов на основе LLM.

Литература

1. G. Fraser and A. Arcuri, “Evosuite: automatic test suite generation for object-oriented software,” in Proceedings of the 19th ACM SIGSOFT symposium and the 13th European conference on Foundations of software engineering, 2011, pp. 416–419.
2. M. L. Siddiq, J. C. Santos, R. H. Tanvir, N. Ulfat, F. Al Rifat, and V. C. Lopes, “Using large language models to generate junit tests: An empirical study,” 2024.
3. Y. Tang, Z. Liu, Z. Zhou, and X. Luo, “Chatgpt vs sbst: A comparative assessment of unit test suite generation,” IEEE Transactions on Software Engineering, 2024.
4. Y. Chen, Z. Hu, C. Zhi, J. Han, S. Deng, and J. Yin, “Chatunitest: A framework for llm-based test generation,” in Companion Proceedings of the 32nd ACM International Conference on the Foundations of Software Engineering, 2024, pp. 572–576.
5. J. Wang, Y. Huang, C. Chen, Z. Liu, S. Wang, and Q. Wang, “Software testing with large language models: Survey, landscape, and vision,” IEEE Transactions on Software Engineering, 2024.
6. W. C. Ouedraogo, K. Kabore, H. Tian, Y. Song, A. Koyuncu, J. Klein, D. Lo, and T. F. Bissyande, “Llms and prompting for unit test generation: A large-scale evaluation,” in Proceedings of the 39th IEEE/ACM International Conference on Automated Software Engineering, 2024, pp. 2464–2465.
7. L. Yang, C. Yang, S. Gao, W. Wang, B. Wang, Q. Zhu, X. Chu, J. Zhou, G. Liang, Q. Wang et al., “On the evaluation of large language models in unit test generation,” in Proceedings of the 39th IEEE/ACM International Conference on Automated Software Engineering, 2024, pp. 1607–1619.
8. W. C. Ouedraogo, K. Kabor ' e, H. Tian, Y. Song, A. Koyuncu, J. Klein, ' D. Lo, and T. F. Bissyande, “Large-scale, independent and comprehen- ' sive study of the power of llms for test case generation,” arXiv preprint arXiv:2407.00225, 2024.
9. T. J. McCabe, “A complexity measure,” IEEE Transactions on software Engineering, no. 4, pp. 308–320, 1976.
10. G. A. Campbell, “Cognitive complexity: A new way of measuring understandability,” https://www.sonarsource.com/docs/CognitiveComplexity. pdf, 2023, version 1.7.
11. M. Biagiola, G. Ghislotti, and P. Tonella, “Improving the readability of automatically generated tests using large language models,” arXiv preprint arXiv:2412.18843, 2024.
12. A. Deljouyi, R. Koohestani, M. Izadi, and A. Zaidman, “Leveraging large language models for enhancing the understandability of generated unit tests,” arXiv preprint arXiv:2408.11710, 2024.
13. D. Winkler, P. Urbanke, and R. Ramler, “Investigating the readability of test code,” Empirical Software Engineering, vol. 29, no. 2, p. 53, 2024.
14. E. Daka, J. Campos, G. Fraser, J. Dorn, and W. Weimer, “Modeling readability to improve unit tests,” in Proceedings of the 2015 10th Joint Meeting on Foundations of Software Engineering, 2015, pp. 107–118.
15. S. Scalabrino, M. Linares-Vasquez, R. Oliveto, and D. Poshyvanyk, ' “A comprehensive model for code readability,” Journal of Software: Evolution and Process, vol. 30, no. 6, p. e1958, 2018.
16. A. Sergeyuk, O. Lvova, S. Titov, A. Serova, F. Bagirov, E. Kirillova, and T. Bryksin, “Reassessing java code readability models with a humancentered approach,” in Proceedings of the 32nd IEEE/ACM International Conference on Program Comprehension, 2024, pp. 225–235.
17. R. Just, D. Jalali, and M. D. Ernst, “Defects4j: A database of existing faults to enable controlled testing studies for java programs,” in Proceedings of the 2014 international symposium on software testing and analysis, 2014, pp. 437–440.
18. A. Panichella, F. M. Kifetew, and P. Tonella, “Automated test case generation as a many-objective optimisation problem with dynamic selection of the targets,” IEEE Transactions on Software Engineering, vol. 44, no. 2, pp. 122–158, 2017.
19. PMD, “PMD An extensible cross-language static code analyzer.” https://pmd.github.io/, 2012, [Online; accessed 06-Jun-2024].
20. A. Hurst, A. Lerer, A. P. Goucher, A. Perelman, A. Ramesh, A. Clark, A. Ostrow, A. Welihinda, A. Hayes, A. Radford et al., “Gpt-4o system card,” arXiv preprint arXiv:2410.21276, 2024.
21. R. P. Buse and W. R. Weimer, “A metric for software readability,” in Proceedings of the 2008 international symposium on Software testing and analysis, 2008, pp. 121–130.
22. ——, “Learning a metric for code readability,” IEEE Transactions on software engineering, vol. 36, no. 4, pp. 546–558, 2009.
23. D. Posnett, A. Hindle, and P. Devanbu, “A simpler model of software readability,” in Proceedings of the 8th working conference on mining software repositories, 2011, pp. 73–82.
24. J. Dorn, “A general software readability model,” MCS Thesis available from (http://www.cs.virginia.edu/weimer/students/dorn-mcs-paper.pdf), vol. 5, pp. 11–14, 2012.
25. Q. Mi, Y. Hao, L. Ou, and W. Ma, “Towards using visual, semantic and structural features to improve code readability classification,” Journal of Systems and Software, vol. 193, p. 111454, 2022.
26. E. Guerra, E. Gomes, J. Ferreira, I. Wiese, P. Lima, M. Gerosa, and P. Meirelles, “How do annotations affect java code readability?” Empirical Software Engineering, vol. 29, no. 3, p. 62, 2024.
27. S. Ren, D. Guo, S. Lu, L. Zhou, S. Liu, D. Tang, N. Sundaresan, M. Zhou, A. Blanco, and S. Ma, “Codebleu: a method for automatic evaluation of code synthesis,” arXiv preprint arXiv:2009.10297, 2020.
28. M. Muñoz Baróon, M. Wyrich, and S. Wagner, “An empirical validation ' of cognitive complexity as a measure of source code understandability,” in Proceedings of the 14th ACM/IEEE international symposium on empirical software engineering and measurement (ESEM), 2020, pp. 1–12.
29. T. Sharma and D. Spinellis, “Do we need improved code quality metrics?” arXiv preprint arXiv:2012.12324, 2020.