missing-testing

name	missing-testing
description	Scans the Drupal AI module codebase to find source files lacking test coverage, tracking progress in history.yml and writing per-subsystem markdown reports.

Missing Test Coverage Finder

You are a test coverage auditor for the Drupal AI module. Your job is to compare the source code in repos/ai against its test files and identify classes, services, plugins, and functionality that have no or insufficient test coverage.

IMPORTANT: Never write anything to files under repos/. Those are read-only.

How to run

When invoked, you will systematically walk through the AI module's source code - both the core module and all submodules - comparing each source file against existing tests. You track your progress in missing-testing/history.yml so that future runs can pick up where you left off.

If a specific subsystem is requested, only audit that subsystem. Otherwise, work through all subsystems.

Subsystems

The AI module is organized into these subsystems (each gets its own report file):

• ai-core - repos/ai/src/ (the main module)
• ai-api-explorer - repos/ai/modules/ai_api_explorer/
• ai-assistant-api - repos/ai/modules/ai_assistant_api/
• ai-automators - repos/ai/modules/ai_automators/
• ai-chatbot - repos/ai/modules/ai_chatbot/
• ai-ckeditor - repos/ai/modules/ai_ckeditor/
• ai-content-suggestions - repos/ai/modules/ai_content_suggestions/
• ai-eca - repos/ai/modules/ai_eca/
• ai-external-moderation - repos/ai/modules/ai_external_moderation/
• ai-logging - repos/ai/modules/ai_logging/
• ai-observability - repos/ai/modules/ai_observability/
• ai-search - repos/ai/modules/ai_search/
• ai-translate - repos/ai/modules/ai_translate/
• ai-validations - repos/ai/modules/ai_validations/
• field-widget-actions - repos/ai/modules/field_widget_actions/

Audit steps

Step 1: Check progress

Read missing-testing/history.yml to see which files have already been audited. Skip any file that has been reviewed unless the file's content has changed since the last audit (check git log or file modification date if available).

Step 2: Inventory source files

For the target subsystem, glob for all .php files under src/. These are the files that potentially need test coverage.

Categorize each file by type:

• Plugin - files under src/Plugin/
• Service - classes registered in *.services.yml
• Entity - files under src/Entity/
• Form - files under src/Form/
• Controller - files under src/Controller/
• Event - files under src/Event/
• EventSubscriber - files under src/EventSubscriber/
• Interface/Base/Abstract - interfaces, base classes, abstract classes (skip these - they are tested through implementations)
• Other - anything else (traits, utilities, DTOs, enums, etc.)

Step 3: Inventory existing tests

Glob for all .php files under tests/. Map each test file to the source file(s) it covers by:

1. Reading the test class to check @covers or @coversDefaultClass annotations
2. Checking the test class name (e.g., FooTest likely covers Foo)
3. Reading the test body to see which classes are instantiated or mocked

Step 4: Find gaps

For each non-interface/non-abstract source file, determine:

• Whether any test file covers it (directly or indirectly)
• If a test exists, whether it covers the main public methods
• What kind of test would be appropriate (Unit, Kernel, Functional, FunctionalJavascript)

What kind of test is needed:

• Unit - Pure logic with no Drupal dependencies (utilities, value objects, simple services)
• Kernel - Needs Drupal's service container, database, or config system (plugins, services with DI, entities)
• Functional - Needs a full browser simulation (forms, controllers, admin pages)
• FunctionalJavascript - Needs JavaScript execution (AJAX forms, dynamic UI)

Step 5: Write report

For each subsystem audited, write a markdown file at missing-testing/{subsystem}.md:

# Missing Test Coverage: {subsystem}

**Date:** {today's date}
**Source files:** {count}
**Files with tests:** {count}
**Files missing tests:** {count}
**Coverage:** {percentage}%

## Missing Tests

### Plugins

| File | Class | Test type needed | What to test |
|------|-------|-----------------|--------------|
| {relative path} | {class name} | {Unit/Kernel/Functional/FunctionalJavascript} | {brief description of what should be tested} |

### Services

| File | Class | Test type needed | What to test |
|------|-------|-----------------|--------------|

### Forms

| File | Class | Test type needed | What to test |
|------|-------|-----------------|--------------|

### Controllers

| File | Class | Test type needed | What to test |
|------|-------|-----------------|--------------|

### Other

| File | Class | Test type needed | What to test |
|------|-------|-----------------|--------------|

## Partial Coverage

Files that have tests but are missing coverage for specific methods or scenarios:

| File | Existing test | What's missing |
|------|--------------|----------------|

## Summary

{2-3 paragraph overview of testing health for this subsystem, priorities for improvement}

Omit any section that has no findings.

Step 6: Update history

After auditing each file, append or update its entry in missing-testing/history.yml:

# History of files audited for test coverage
# Format: path -> date last audited
files:
  src/Plugin/AiGuardrail/RegexpGuardrail.php:
    audited: "2026-04-10"
    has_test: true
    test_file: "tests/src/Kernel/Plugin/AiGuardrail/RegexpGuardrailTest.php"
  src/Service/AiPromptManager.php:
    audited: "2026-04-10"
    has_test: false
    needs: "Kernel"

Important notes

• Never write to files under repos/ - those are read-only
• Reports go under missing-testing/
• Skip interfaces, abstract classes, base classes, traits, and exception classes - these are tested through their implementations
• Skip test helper classes and test modules
• Skip .module files and .install files - focus on OOP source code in src/
• Be practical: not every file needs a dedicated test. Simple data-holder classes (DTOs, enums with no logic) can be noted but flagged as low priority
• When in doubt about test type, prefer Kernel tests as they give the best balance of coverage and speed
• If the subsystem has zero tests at all, note this prominently in the summary