improving-frontend-coverage

Führt Frontend-Komponententests mit Abdeckung aus, analysiert Abdeckungsberichte und implementiert sinnvolle Tests, um die Abdeckung um ~0,2 % zu erhöhen. Verwenden Sie, wenn Sie…

npx skills add https://github.com/streamlit/streamlit --skill improving-frontend-coverage

Improving frontend coverage

Increase frontend 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

COVERAGE_JSON=1 make frontend-tests  # ~5 min

Reports generated in frontend/coverage/:

  • coverage-summary.json - Per-file percentages (lines, branches, functions)
  • coverage-final.json - Line-level data with uncovered line numbers (hit count 0 in s, f, b maps)

Step 2: Analyze and prioritize

Read coverage-summary.json to find files with:

  1. Large size + below-average coverage (high impact)
  2. Core components in lib/src/components/
  3. Utility functions in utils/src/

Skip: >97% coverage, auto-generated, .d.ts, 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 uncovered lines from coverage-final.json
  • 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 to understand gaps
  2. Write tests for: conditional rendering, event handlers, error states, edge cases, accessibility
  3. Follow RTL best practices: query by role/label, test behavior not implementation
  4. Run the new tests to verify they pass: cd frontend && yarn test path/to/Component.test.tsx

Step 4: Verify and iterate

cd frontend && yarn test path/to/Component.test.tsx  # Run new tests
COVERAGE_JSON=1 make frontend-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 rendering, user interactions, prop variations, error handling, accessibility, edge cases (null, empty, max values).

DON'T test: Pass-through props, styling, library internals, implementation details, already well-covered code.

Coverage exclusions: Use /* istanbul ignore next */ sparingly for code that genuinely doesn't need testing. Always include a reason (e.g., /* istanbul ignore next -- defensive */):

  • Browser-specific branches that can't run in jsdom (/* istanbul ignore next -- browser-only */)
  • Defensive fallbacks that should never execute (/* istanbul ignore next -- defensive */)
  • Framework-required boilerplate (/* istanbul ignore next -- exhaustive */)

Notes

  • Quality > coverage numbers - skip tests that don't catch real bugs
  • Test files: co-located as <Component>.test.tsx
  • Use /checking-changes after implementing tests

Mehr Skills von streamlit

developing-with-streamlit
streamlit
**[ERFORDERLICH]** Für ALLE Streamlit-Aufgaben verwenden: Erstellen, Bearbeiten, Debuggen, Verschönern, Stylen, Theming oder Optimieren von Streamlit-Anwendungen. Ebenfalls erforderlich…
official
addressing-pr-review-comments
streamlit
Behandelt alle gültigen Review-Kommentare zu einem PR für den aktuellen Branch im streamlit/streamlit-Repository. Deckt sowohl Inline-Review-Kommentare als auch allgemeine PR-(Issue-)…
official
checking-changes
streamlit
Validiert alle Codeänderungen vor dem Commit durch Ausführen von Format-, Lint-, Typ- und Unit-Test-Prüfungen. Verwenden nach Backend- (Python) oder Frontend- (TypeScript)…
official
discovering-make-commands
streamlit
Listet verfügbare Make-Befehle für die Streamlit-Entwicklung auf. Verwenden für Build-, Test-, Lint- oder Formatierungsaufgaben.
official
finalizing-pr
streamlit
Schließt Branch-Änderungen für das Mergen ab, indem Code vereinfacht, Checks ausgeführt, Änderungen überprüft und bei Bedarf ein PR erstellt wird. Verwenden, wenn bereit, Änderungen in … zu mergen.
official
fixing-flaky-e2e-tests
streamlit
Diagnostiziere und behebe flaky Playwright e2e-Tests. Verwende, wenn Tests zeitweise fehlschlagen, Timeout-Fehler auftreten, Snapshot-Abweichungen vorliegen oder browserspezifische…
official
fixing-streamlit-ci
streamlit
Analysieren und beheben Sie fehlgeschlagene GitHub Actions CI-Jobs für den aktuellen Branch/PR. Verwenden Sie dies, wenn CI-Prüfungen fehlschlagen, PR-Prüfungen Fehler anzeigen oder Sie Diagnosen benötigen…
official
generating-changelog
streamlit
Erstellt polierte Website-Versionshinweise zwischen zwei Git-Tags für docs.streamlit.io. Verwenden Sie dies bei der Vorbereitung einer neuen Streamlit-Version oder beim Überprüfen von Änderungen zwischen…
official