improving-frontend-coverage

द्वारा streamlit

फ्रंटएंड यूनिट टेस्ट को कवरेज के साथ चलाता है, कवरेज रिपोर्ट का विश्लेषण करता है, और कवरेज को लगभग 0.2% बढ़ाने के लिए सार्थक टेस्ट लागू करता है। इसका उपयोग तब करें जब आप चाहते हैं…

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

streamlit की और Skills

developing-with-streamlit
streamlit
**[आवश्यक]** सभी Streamlit कार्यों के लिए उपयोग करें: Streamlit एप्लिकेशन बनाना, संपादित करना, डीबग करना, सुंदर बनाना, स्टाइल करना, थीमिंग या ऑप्टिमाइज़ करना। इसके अलावा आवश्यक…
official
addressing-pr-review-comments
streamlit
स्ट्रीमलिट/स्ट्रीमलिट रिपॉजिटरी में वर्तमान ब्रांच के PR पर सभी वैध समीक्षा टिप्पणियों को संबोधित करें। इसमें इनलाइन समीक्षा टिप्पणियाँ और सामान्य PR (मुद्दा) दोनों शामिल हैं…
official
checking-changes
streamlit
कमिट करने से पहले फ़ॉर्मेट, लिंट, टाइप और यूनिट टेस्ट जाँच चलाकर सभी कोड परिवर्तनों को मान्य करता है। बैकएंड (Python) या फ्रंटएंड (TypeScript) बनाने के बाद उपयोग करें…
official
discovering-make-commands
streamlit
स्ट्रीमलिट विकास के लिए उपलब्ध मेक कमांड्स को सूचीबद्ध करता है। बिल्ड, टेस्ट, लिंट या फॉर्मेट कार्यों के लिए उपयोग करें।
official
finalizing-pr
streamlit
शाखा में हुए बदलावों को मर्ज करने के लिए अंतिम रूप देता है, कोड को सरल बनाकर, जाँच चलाकर, बदलावों की समीक्षा करके और यदि आवश्यक हो तो PR बनाकर। तब उपयोग करें जब बदलावों को मर्ज करने के लिए तैयार हों...
official
fixing-flaky-e2e-tests
streamlit
निदान करें और अस्थिर Playwright e2e परीक्षणों को ठीक करें। तब उपयोग करें जब परीक्षण बीच-बीच में विफल हों, टाइमआउट त्रुटियाँ दिखाएँ, स्नैपशॉट बेमेल हों, या ब्राउज़र-विशिष्ट…
official
fixing-streamlit-ci
streamlit
वर्तमान शाखा/PR के लिए विफल GitHub Actions CI कार्यों का विश्लेषण और सुधार करें। इसका उपयोग तब करें जब CI जाँच विफल हों, PR जाँच में विफलताएँ दिखें, या आपको निदान करने की आवश्यकता हो…
official
generating-changelog
streamlit
दो git टैग्स के बीच docs.streamlit.io के लिए पॉलिश की गई वेबसाइट रिलीज़ नोट्स तैयार करता है। नए Streamlit रिलीज़ की तैयारी करते समय या बीच के बदलावों की समीक्षा करते समय उपयोग करें।
official