Skip to content
Code Review
Skill

/improving-python-coverage

Runs Python unit tests with coverage, analyzes coverage reports, and implements meaningful tests to increase coverage by ~0.2%. Use when you want to systematically improve Python test coverage with high-value test cases.

From plugin
streamlit
46k21 skills4 agents4 commands

Claude Code

$ npx -y skills add streamlit/streamlit --skill improving-python-coverage --agent claude-code

SKILL.md

improving-python-coverage.SKILL.md
name: improving-python-coverage
description: Runs Python unit tests with coverage, analyzes coverage reports, and implements meaningful tests to increase coverage by ~0.2%. Use when you want to systematically improve Python test coverage with high-value test cases.

Improving Python coverage

Increase Python unit test coverage by ~0.2% through meaningful tests that add real value.

**Be fully autonomous** — Do NOT stop or pause to ask for confirmation. Keep iterating (analyze → implement → verify) until the 0.2% coverage target is reached. If you encounter ambiguities about what to test, make a reasonable choice and proceed.

Workflow

**Step 1: Run tests with coverage**

make python-tests  # ~3 min, creates .coverage file

Generate JSON report for analysis:

uv run coverage json -o coverage.json

The JSON contains per-file `missing_lines` arrays showing uncovered line numbers.

**Step 2: Analyze and prioritize**

Read `coverage.json` to find files with: 1. Large size + below-average `percent_covered` (high impact) 2. Core modules in `lib/streamlit/elements/` or `lib/streamlit/runtime/` 3. Pure utility functions

Skip: >97% coverage, `proto/*`, `vendor/*`, `static/*`, test files.

**Step 3: Implement tests (in subagent)**

Launch a subagent to implement tests for each prioritized file. Provide the subagent with:

  • The target file path and its `missing_lines` from coverage
  • Instructions to read the source, existing tests, and write new tests
  • The test selection guidelines below

The subagent should: 1. Read source and existing tests at `lib/tests/streamlit/<path>/<module>_test.py` 2. Write tests for: conditional branches, error handling, edge cases, exception paths 3. Follow `lib/tests/AGENTS.md`: prefer pytest-style standalone functions over `unittest.TestCase` classes, use `@pytest.mark.parametrize` to consolidate tests that only differ in inputs/expected outputs, add numpydoc docstrings and type annotations 4. Run the new tests to verify they pass: `uv run pytest lib/tests/streamlit/path/to/module_test.py -v`

**Step 4: Verify and iterate**

uv run pytest lib/tests/streamlit/path/to/module_test.py -v  # Run new tests
make python-tests                                             # Measure progress

**Repeat steps 2-4 until coverage improves by ≥0.2%**, then run `make check`.

**Step 5: Simplify, review, and address feedback**

Once all tests pass and coverage target is met:

1. Run the `simplifying-local-changes` subagent to clean up and simplify the code changes. Wait for completion. 2. Run the `reviewing-local-changes` subagent to review the changes. Wait for completion and read the review output. 3. Address the review feedback: for each recommendation, implement it if valid and improves code quality; skip with brief reasoning if not applicable or would over-engineer. 4. Run /checking-changes to verify everything still passes after changes.

Test selection

**DO test:** Conditional logic, error handling, edge cases (None, empty, zero, max), public API functions, complex branches.

**DON'T test:** Simple accessors, protobufs, implementation details, already well-covered code.

**Coverage exclusions:** Use `# pragma: no cover` sparingly for code that genuinely doesn't need testing. Always include a reason (e.g., `# pragma: no cover - defensive`):

  • Platform-specific branches that can't run in CI (`# pragma: no cover - platform-specific`)
  • Defensive code that should never execute (`# pragma: no cover - defensive`)
  • Abstract method stubs or protocol definitions (`# pragma: no cover - abstract`)

**Integration dependencies:** Packages listed under `[dependency-groups] integration` in `pyproject.toml` (e.g., `pydantic`, `sympy`, `polars`, `sqlalchemy`) are only installed for integration tests, not regular unit tests. When writing tests that use these packages:

  • Import them **inside the test function**, not at module top-level
  • Add `@pytest.mark.require_integration` marker to the test
  • This ensures tests gracefully skip when run outside the integration test environment

Test file location

`lib/tests/streamlit/<package>/<module>_test.py` mirrors `lib/streamlit/<package>/<module>.py`

Notes

  • Quality > coverage numbers - skip tests that don't catch real bugs
  • Target is 95%+ coverage per `lib/tests/AGENTS.md`
  • Use `/checking-changes` after implementing tests
  • Some code paths involving external libraries (e.g., database connectors, optional dependencies) are already covered by integration tests marked with `pytest.mark.require_integration`. These integration tests are **not** included in the coverage numbers from `make python-tests`. When analyzing missing lines, check whether the uncovered code is exercised by integration tests before adding unit tests or `# pragma: no cover` annotations.
  • **Local vs CI coverage differences:** Code that is version-specific (Python version, library version) or uses integration dependencies may appear uncovered locally but is tested and covered in CI. Examples:
  • Python version-specific branches (e.g., `if sys.version_info >= (3, 14)`) run only on matching CI jobs
  • Library version-specific code (e.g., pandas 2.x vs 3.x behavior) is covered across CI matrix
  • Integration dependency tests (`@pytest.mark.require_integration`) run in separate CI jobs with those packages installed

Before adding tests or `# pragma: no cover` for such code, verify whether it's already exercised in CI.

Read more
@streamlit
Ships withstreamlit

A faster way to build and share data apps.

46k21 skills4 agents
Get the whole plugin

Stars on GitHub

Momentum

stars in total
46.3k
Star history of streamlit/streamlit on GitHub, a chart by star-history.com

Other skills on streamlit.

checking-changes

checking-changes

Validates all code changes before committing by running format, lint, type, and unit test checks. Use after making backend…

@streamlit@streamlitInstall Skill
creating-pull-requests

creating-pull-requests

Creates a draft pull request on GitHub with proper labels, branch naming, and description formatting. Use when changes are ready…

@streamlit@streamlitInstall Skill
debugging-streamlit

debugging-streamlit

Debug Streamlit frontend and backend changes using make debug with hot-reload. Use when testing code changes, investigating bugs,…

@streamlit@streamlitInstall Skill

More skills from other plugins.

open-code-review

open-code-review

Performs AI-powered code review on Git changes using the `ocr` CLI from alibaba/open-code-review. Use when the user asks to…

@alibaba@alibabaInstall Skill
build-graph

build-graph

Build or update the code review knowledge graph. Run this first to initialize, or let hooks keep it updated automatically.

@tirth8205@tirth8205Install Skill
hunk-extensions

hunk-extensions

Maps the `hunkdiff/extension` authoring surface for Hunk, the terminal diff viewer — hiding or reordering reviewed files, docked…

hunk2d9.8k
@modem-dev@modem-devInstall Skill
install-anti-slop

install-anti-slop

Install, configure, update, or upgrade vendored anti-slop Oxlint plugins. Use when adding anti-slop, picking up upstream rules or…

anti-slop4w5.8k
@dmmulroy@dmmulroyInstall Skill

Questions about improving-python-coverage.

Which coding agents can use improving-python-coverage?
improving-python-coverage installs in Claude Code, Codex, Cursor, Gemini CLI, GitHub Copilot, OpenCode and Windsurf with the skills CLI, using each agent's flag shown on this page. Flowy's auto-invocation, which fires a skill when your prompt matches, runs in Claude Code only.