test: increase test coverage to 80%

Daniel Scholl (MS]requested to merge
tests into main

  • Concise summary

    • Expanded and hardened the test suite across CLI commands and core analyzers (Contributions, Decisions, Trends), including date-range handling, output formats, and option propagation to analyzers.
    • Introduced and validated behavior for max_workers cap across analyzers (capped at 10).
    • Adjusted the test coverage threshold in the project config (fail_under increased).
    • Added tests that simulate GitLab errors (GitlabGetError) to ensure graceful handling.
    • The diff primarily adds extensive test coverage; no production code changes are shown outside the configuration threshold.

  • Key modifications and their purpose

    • pyproject.toml
      • fail_under increased from 58 to 75 to raise the minimum test coverage threshold for the project.
    • tests/test_cli.py
      • Added integration-style tests for CLI commands:
        • contribution command with JSON and Markdown outputs, ensuring JSON/Markdown content and metadata presence.
        • verification that CLI passes options through to the ContributionAnalyzer (days, start_date, end_date, project_filter, token, verbose).
        • date-range behavior for explicit start_date and end_date handling is exercised.
        • trend, decision, and update command paths tested to ensure proper analyzer invocation and output formats.
    • tests/test_contributions.py
      • Added tests for:
        • Contributions date-range handling (end_date with days, start_date only, etc.).
        • Project filtering behavior (case-insensitive, all projects when no filter).
        • Analyzer behavior under GitLab API error conditions (GitlabGetError) and data extraction paths.
        • Update statistics logic for aggregating per-project contributions, approvals, reviews, and per-contributor stats.
        • Project and contributor statistics creation/accumulation across multiple projects.
    • tests/test_decisions.py
      • Added tests mirroring Contributions for ADRs:
        • End-to-end ADR analysis via _analyze_project with various project states and labels.
        • Date-range handling for decisions (end_date with days, start_date, etc.).
        • Filtering behavior and error-handling paths (GitlabGetError).
        • Verification of ADR data extraction (title, is_proposed, is_approved, participants, notes/discussions).
        • Update statistics for ADRs, participants, and project-level stats.
    • tests/test_trends.py
      • Added tests for TrendsAnalyzer:
        • Max workers cap at 10.
        • Validation of period dates and month buckets.
        • Project analysis behavior with mocked GitLab data.
        • Bucketing of MRs into periods and aggregation of period-level statistics.
        • Update statistics and accumulation across multiple projects.
        • Handling of GitLabGetError in project analysis paths.
    • Notable technical details in tests
      • Extensive use of mocks and patches (e.g., patch("osdu_engagement.core.contributions.ContributionAnalyzer"), patch("osdu_engagement.core.trends.TrendsAnalyzer"), etc.) to isolate CLI behavior from internals.
      • Assertions that outputs contain expected JSON/Markdown sections (e.g., presence of "metadata", "contributions", "trends", "decisions", "adrs").
      • Date-range logic expectations validated in multiple analyzers:
        • When end_date and days are provided, filter_by_date is enabled and start_date/end_date reflect a 30-day window (e.g., end_date 2024-06-30, start_date 2024-05-31 in tests).
        • When only start_date is provided, end_date is present (not None).
    • Security impact analysis (vulnerability data)
      • The changes introduce tests that simulate GitLab API errors using GitlabGetError to ensure graceful handling paths are exercised and do not crash in production.
      • No new security vulnerabilities are introduced in production code; tests primarily validate error resilience and data extraction logic under failure scenarios.
      • No vulnerabilities are fixed in the diff; vulnerability data is not provided beyond test scaffolding for error handling.

  • Notable technical details (specific behaviors validated)

    • Date-range calculations are validated for end_date with days, ensuring the start_date is calculated to cover the intended window.
    • Max workers cap is enforced consistently across Contributions, Decisions, and Trends analyzers (tests expect max_workers == 10 when instantiated with higher values).
    • CLI tests verify that CLI options (--days, --start-date, --end-date, --project, --token, --verbose, --output) are correctly passed to the respective analyzers.
    • Output verification checks for presence of expected sections in JSON/Markdown (e.g., metadata, contributions, adrs, trends, decisions).

Last specific change or security finding discussed

  • class TestTrendMetrics:

Merge request reports