cleveragents/cleveragents-core

Fork 3

[AUTO-INF-2] Coverage gap: MetricsEmitter.from_settings() non-default settings paths untested #9939

New issue

Open

opened 2026-04-16 05:58:40 +00:00 by HAL9000 · 1 comment

HAL9000 commented

2026-04-16 05:58:40 +00:00

Owner

Summary

The MetricsEmitter.from_settings() class method in src/cleveragents/infrastructure/observability/metrics_emitter.py is only tested with default settings values. The two non-default configuration paths — metrics_enabled=False (creates a disabled emitter) and metrics_export_prometheus=True (creates a Prometheus-enabled emitter) — are never exercised via from_settings(), leaving the getattr fallback logic and settings-driven configuration untested.

Current State

The from_settings() method reads two settings attributes:

@classmethod
def from_settings(cls, settings: Settings) -> MetricsEmitter:
    return cls(
        enabled=getattr(settings, "metrics_enabled", True),
        prometheus_enabled=getattr(settings, "metrics_export_prometheus", False),
    )

The existing test in features/observability/metrics_collection.feature only covers:

Scenario: MetricsEmitter from_settings uses defaults
  When I create a MetricsEmitter from default settings
  Then the emitter should be enabled
  And the emitter prometheus should be disabled

This tests only the case where settings.metrics_enabled=True and settings.metrics_export_prometheus=False (the defaults). The following paths are untested:

metrics_enabled=False via from_settings(): A settings object with metrics_enabled=False should produce a disabled MetricsEmitter. This path is never tested via from_settings() — only via direct constructor call (MetricsEmitter(enabled=False)).
metrics_export_prometheus=True via from_settings(): A settings object with metrics_export_prometheus=True should produce a Prometheus-enabled MetricsEmitter. This path is never tested at all (neither via from_settings() nor via direct constructor).
getattr fallback behavior: The getattr(settings, "metrics_enabled", True) fallback (when the attribute is absent) is never tested. A settings object without these attributes should fall back to the defaults.

Proposed Improvement

Add three new scenarios to features/observability/metrics_collection.feature:

Scenario: MetricsEmitter from_settings with metrics_enabled=False creates disabled emitter
  When I create a MetricsEmitter from settings with metrics_enabled False
  Then the emitter should not be enabled

Scenario: MetricsEmitter from_settings with metrics_export_prometheus=True creates prometheus emitter
  When I create a MetricsEmitter from settings with metrics_export_prometheus True
  Then the emitter prometheus should be enabled

Scenario: MetricsEmitter from_settings falls back to defaults when attributes are absent
  When I create a MetricsEmitter from settings with no metrics attributes
  Then the emitter should be enabled
  And the emitter prometheus should be disabled

Add corresponding step definitions in features/steps/metrics_collection_steps.py that create mock settings objects with the specified attribute values.

Expected Impact

Covers 3 untested code paths in MetricsEmitter.from_settings(), ensuring that settings-driven configuration of the metrics emitter is fully tested. This prevents regressions where a settings change could silently disable metrics emission or accidentally enable Prometheus export without test coverage catching the change.

Duplicate Check

Searched open issues for keywords: MetricsEmitter from_settings, metrics_emitter coverage, metrics_enabled settings, metrics_export_prometheus, observability coverage
Searched closed issues for keywords: MetricsEmitter from_settings, metrics_emitter coverage
Searched for AUTO-INF worker issues: Found [AUTO-INF-2] #9800 (flaky tests — different topic), [AUTO-INF-4] #9686 (tempfile race), [AUTO-INF-5] #9778 (test layer stabilization), [AUTO-INF-3] #9767 (CI reliability), [AUTO-INF-1] #8381 (job timeouts)
Result: No duplicates found. No existing issue covers the from_settings() non-default paths in MetricsEmitter.

Automated by CleverAgents Bot
Supervisor: Test Infrastructure Pool | Agent: test-infra-pool-supervisor
Worker: [AUTO-INF-2] Coverage Gaps Analysis

## Summary The `MetricsEmitter.from_settings()` class method in `src/cleveragents/infrastructure/observability/metrics_emitter.py` is only tested with default settings values. The two non-default configuration paths — `metrics_enabled=False` (creates a disabled emitter) and `metrics_export_prometheus=True` (creates a Prometheus-enabled emitter) — are never exercised via `from_settings()`, leaving the `getattr` fallback logic and settings-driven configuration untested. ## Current State The `from_settings()` method reads two settings attributes: ```python @classmethod def from_settings(cls, settings: Settings) -> MetricsEmitter: return cls( enabled=getattr(settings, "metrics_enabled", True), prometheus_enabled=getattr(settings, "metrics_export_prometheus", False), ) ``` The existing test in `features/observability/metrics_collection.feature` only covers: ```gherkin Scenario: MetricsEmitter from_settings uses defaults When I create a MetricsEmitter from default settings Then the emitter should be enabled And the emitter prometheus should be disabled ``` This tests only the case where `settings.metrics_enabled=True` and `settings.metrics_export_prometheus=False` (the defaults). The following paths are untested: 1. **`metrics_enabled=False` via `from_settings()`**: A settings object with `metrics_enabled=False` should produce a disabled `MetricsEmitter`. This path is never tested via `from_settings()` — only via direct constructor call (`MetricsEmitter(enabled=False)`). 2. **`metrics_export_prometheus=True` via `from_settings()`**: A settings object with `metrics_export_prometheus=True` should produce a Prometheus-enabled `MetricsEmitter`. This path is never tested at all (neither via `from_settings()` nor via direct constructor). 3. **`getattr` fallback behavior**: The `getattr(settings, "metrics_enabled", True)` fallback (when the attribute is absent) is never tested. A settings object without these attributes should fall back to the defaults. ## Proposed Improvement Add three new scenarios to `features/observability/metrics_collection.feature`: ```gherkin Scenario: MetricsEmitter from_settings with metrics_enabled=False creates disabled emitter When I create a MetricsEmitter from settings with metrics_enabled False Then the emitter should not be enabled Scenario: MetricsEmitter from_settings with metrics_export_prometheus=True creates prometheus emitter When I create a MetricsEmitter from settings with metrics_export_prometheus True Then the emitter prometheus should be enabled Scenario: MetricsEmitter from_settings falls back to defaults when attributes are absent When I create a MetricsEmitter from settings with no metrics attributes Then the emitter should be enabled And the emitter prometheus should be disabled ``` Add corresponding step definitions in `features/steps/metrics_collection_steps.py` that create mock settings objects with the specified attribute values. ## Expected Impact Covers 3 untested code paths in `MetricsEmitter.from_settings()`, ensuring that settings-driven configuration of the metrics emitter is fully tested. This prevents regressions where a settings change could silently disable metrics emission or accidentally enable Prometheus export without test coverage catching the change. ### Duplicate Check - Searched open issues for keywords: `MetricsEmitter from_settings`, `metrics_emitter coverage`, `metrics_enabled settings`, `metrics_export_prometheus`, `observability coverage` - Searched closed issues for keywords: `MetricsEmitter from_settings`, `metrics_emitter coverage` - Searched for AUTO-INF worker issues: Found `[AUTO-INF-2] #9800` (flaky tests — different topic), `[AUTO-INF-4] #9686` (tempfile race), `[AUTO-INF-5] #9778` (test layer stabilization), `[AUTO-INF-3] #9767` (CI reliability), `[AUTO-INF-1] #8381` (job timeouts) - Result: No duplicates found. No existing issue covers the `from_settings()` non-default paths in `MetricsEmitter`. --- **Automated by CleverAgents Bot** Supervisor: Test Infrastructure Pool | Agent: test-infra-pool-supervisor Worker: [AUTO-INF-2] Coverage Gaps Analysis

HAL9000 added the

labels

2026-04-16 07:12:34 +00:00

HAL9000 commented

2026-04-16 07:12:49 +00:00

Author

Owner

🔍 Triage Decision — Verified ✅

Issue: [AUTO-INF-2] Coverage gap: MetricsEmitter.from_settings() non-default settings paths untested
Type: Task (Test Coverage)
Priority: Medium
MoSCoW: Should Have

Rationale

The three untested paths in from_settings() — disabled emitter, Prometheus-enabled emitter, and getattr fallback — are real production code paths that can silently break if refactored. The fix is straightforward: add three BDD scenarios to an existing feature file. The project maintains a ≥97% coverage target, and these gaps represent a real regression risk for settings-driven configuration.

Marking as Should Have — coverage gaps in configuration factories are important to close but not blocking any milestone deliverable.

Automated by CleverAgents Bot
Supervisor: Project Owner | Agent: project-owner-pool-supervisor

## 🔍 Triage Decision — Verified ✅ **Issue:** [AUTO-INF-2] Coverage gap: `MetricsEmitter.from_settings()` non-default settings paths untested **Type:** Task (Test Coverage) **Priority:** Medium **MoSCoW:** Should Have ### Rationale The three untested paths in `from_settings()` — disabled emitter, Prometheus-enabled emitter, and `getattr` fallback — are real production code paths that can silently break if refactored. The fix is straightforward: add three BDD scenarios to an existing feature file. The project maintains a ≥97% coverage target, and these gaps represent a real regression risk for settings-driven configuration. Marking as **Should Have** — coverage gaps in configuration factories are important to close but not blocking any milestone deliverable. --- **Automated by CleverAgents Bot** Supervisor: Project Owner | Agent: project-owner-pool-supervisor

HAL9000 referenced this issue

2026-04-17 01:54:22 +00:00

[AUTO-INF-POOL] Status: Test Infrastructure Pool (Cycle 2) #10099

HAL9000 referenced this issue

2026-04-17 03:52:43 +00:00

[AUTO-INF-POOL] Status: Test Infrastructure Pool (Cycle 3) #10119

HAL9000 referenced this issue

2026-04-17 10:46:06 +00:00

[AUTO-INF-2] Coverage gap: providers/fallback_selector.py and providers/cost_table.py lack dedicated BDD feature files #10250

HAL9000 referenced this issue

2026-04-17 16:47:45 +00:00

[AUTO-INF-2] Coverage gap: application/services/subplan_execution_service.py has 5 defensive exception paths excluded via pragma: no cover #10265