quality-test-implementation

Multi-Language Code Quality & Test Coverage

Role

Senior SRE Engineer focused on quality, stability, and technical-debt reduction across multi-language codebases.

Goal

Perform a comprehensive intervention in the target repository to stabilize the build, reduce static-analysis warnings, raise test coverage to the language target, apply high-level architectural patterns, and produce a measured improvement report — without auto-opening a Pull Request.

When to Use

• A repository (.NET, Java, or Python) has accumulated warnings, smells, or suppressed exceptions.
• Test coverage is below the language target and needs a structured push.
• Technical debt must be reduced before a release or handoff.
• Security CVEs (NU1903, OWASP, Bandit, Safety, Snyk) must be cleared.

When NOT to use: one small file, a single change review, or a quick lint pass. For reviewing a single change, use code-review-and-quality.

Inputs

• REPO_NAME: full name (owner/repo).
• BASE_BRANCH: branch to start from (default main/develop).
• OUTPUT_BRANCH: feature/{YYYYMMDD}-{function-name}.
• PRIMARY_LANGUAGE: dotnet, java, or python.

---

Phase 1 — Preparation and Environment

1. Clone {REPO_NAME} if not already present.
2. Create working branch feature/{YYYYMMDD}-{function-name}.
3. Identify the build/test tooling:
   • .NET: *.sln, *.csproj, Directory.Build.props, global.json.
   • Java: pom.xml (Maven) or build.gradle* (Gradle).
   • Python: pyproject.toml, setup.py, requirements*.txt, tox.ini.
4. Keep any Environment.SetEnvironmentVariable("Testing", "true") (or equivalent) inside the test execution context only.

---

Phase 2 — Static Analysis and Warning Correction

Run the appropriate static-analysis tools and fix the following categories.

.NET

Tools: dotnet build, dotnet test, dotnet format, SonarScanner, Roslyn analyzers.

Java

Tools: mvn compile, mvn test, mvn spotbugs:spotbugs, mvn checkstyle:checkstyle, mvn org.owasp:dependency-check-maven:check.

Python

Tools: ruff check ., ruff format ., mypy, pylint, bandit -r ., pytest --cov=src --cov-report=xml.

---

Phase 3 — Architecture and Style

Refactor only when it reduces warnings or improves testability.

SOLID

• Single Responsibility: split classes/modules that mix persistence, business logic, and presentation.
• Dependency Inversion: depend on abstractions (interfaces/abstract classes/protocols) instead of concrete implementations.

DDD

• Identify Aggregates, Entities, Value Objects, and Repositories.
• Keep domain logic independent of frameworks and UI.

Clean Architecture

• Validate separation between Domain, Application, Infrastructure, and Presentation.
• Domain must not depend on external frameworks, databases, or UI libraries.

---

Phase 4 — Tests and Coverage

For framework-specific commands (xUnit/NUnit/MSTest, Maven/Gradle, pytest/unittest), thresholds, and HTML reports, see the references/ files:

• references/coverage-dotnet.md
• references/coverage-java.md
• references/coverage-python.md

Use the auxiliary dispatcher to auto-detect the stack and run coverage:

bash references/run-coverage.sh

.NET

dotnet test --collect:"XPlat Code Coverage" --results-directory ./TestResults

Java

mvn test
# or
./gradlew test jacocoTestReport

Python

pytest --cov=src --cov-report=term-missing --cov-report=xml

Stabilization Rules

• Fix existing failures before creating new tests.
• Remove or skip problematic infrastructure tests (e.g. JWT, external APIs) only when they require deep refactoring, and document the reason.
• New tests follow BDD style: Given / When / Then (or Dado / Quando / Então for pt-BR projects).

Coverage Goals

Generate reports with reportgenerator (.NET), JaCoCo (Java), or pytest-coverage (Python).

---

Phase 5 — Documentation and Delivery

README.md

Update with:

• Repository structure (hierarchical tree with descriptions).
• Test coverage table: Total Tests, % Lines, % Branches.
• Technical stack list.
• Business Vision and Technical Vision sections.

CHANGELOG.md

• Follow Keep a Changelog
• Use Semantic Versioning
• Link the changelog in the README.

Finalization

Use Conventional Commits:

• feat: — new features
• fix: — bug fixes
• test: — tests
• docs: — documentation
• refactor: — refactorings
• chore: — maintenance tasks

Restriction: Do not open the Pull Request automatically. Prepare the commit, update the README/CHANGELOG, and generate a Detailed Technical Summary containing all changes so the user can open the PR manually.

---

Quality Checklist

• No high/critical security vulnerabilities remain.
• Static-analysis warnings reduced to acceptable baseline.
• All existing tests pass.
• Coverage report generated and meets the language target.
• README updated with coverage and architecture sections.
• CHANGELOG updated with Unreleased changes.
• Commit message follows Conventional Commits.

Common Mistakes

References

• references/coverage-dotnet.md — .NET coverage (xUnit/NUnit/MSTest, Coverlet, reportgenerator, thresholds).
• references/coverage-java.md — Java coverage (Maven JaCoCo, Gradle JaCoCo, thresholds).
• references/coverage-python.md — Python coverage (pytest-cov, unittest + coverage.py, mypy, thresholds).
• references/run-coverage.sh — Stack-detecting dispatcher that runs the right coverage command.

See Also

• For reviewing a single change before merge, see code-review-and-quality.
• For automated SonarQube issue remediation across stacks, see sonarqube-review.

Origin

Adapted from the devin/playbooks/multi-language-quality/PLAYBOOK.md playbook into an agentskills.io-format skill, following the catalog standards (license: MIT, metadata.version, tripartite description with explicit Do NOT use for clause).