js-in-html-testing

Solid

Test JS logic embedded in HTML using two-layer strategy - Python unit tests + Playwright browser integration tests

Testing & QA 1,021 stars 109 forks Updated today MIT

Install

View on GitHub

Quality Score: 96/100

Stars 20%
100
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
50
License 10%
100
Description 5%
100

Skill Content

# JS-in-HTML Two-Layer Testing Strategy For JavaScript logic embedded in HTML files (e.g., diff navigation in viewer.html), use a two-layer testing approach. ## Layer 1: Python Unit Tests (fast algorithm verification) Replicate core JS algorithms in Python and verify correctness via pytest. Best for: pure computation logic, state decisions, matching algorithms — anything that doesn't depend on the DOM. **Example**: `tests/test_diff_matching.py` ```python # Replicate JS findPrevSameModel / findNextSameModel def find_diff_parent_by_prefix(entries, idx): ... def find_next_by_prefix(entries, idx): ... # Replicate JS updateNavButtons state computation def compute_nav_button_states(entries, cur_idx): prev_idx = find_diff_parent_by_prefix(entries, cur_idx) ... return (prev_enabled, next_enabled) ``` Advantages: fast (0.02s), no browser dependency, integrates with existing pytest setup. ## Layer 2: Playwright Browser Integration Tests (DOM interaction verification) Generate HTML with test data embedded, open it in real Chromium via Playwright, and verify DOM state and user interactions. Best for: button disabled states, overlay show/hide, keyboard events, click navigation, etc. **Example**: `tests/test_nav_browser.py` ### Building test HTML ```python def _build_test_html(): from claude_tap.viewer import VIEWER_SCRIPT_ANCHOR, _read_viewer_template template = _read_viewer_template() records = [json.dumps(e) for e in TEST_ENTRIES] data...

Details

Author
liaohch3
Repository
liaohch3/claude-tap
Created
3 months ago
Last Updated
today
Language
Python
License
MIT

Integrates with

Similar Skills

Semantically similar based on skill content — not just same category

Testing & QA Listed

webapp-testing

Toolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser logs.

4 Updated today
bloody2634
Testing & QA Listed

playwright

Browser automation and end-to-end testing with Playwright (Python and TypeScript). TRIGGER when: user asks about browser automation, e2e testing, web scraping with a browser, Playwright setup, page navigation, selectors, screenshots, PDF generation, network interception, file uploads, auth flows, mobile viewports, or accessibility testing with Playwright. Also when code imports playwright, @playwright/test, pytest-playwright, or references playwright.config. DO NOT TRIGGER when: user asks about Cypress, Selenium, Puppeteer, or other browser automation tools; unit testing without a browser; HTTP-only scraping (use requests/httpx); or general pytest usage without Playwright.

1 Updated 1 weeks ago
DROOdotFOO
Testing & QA Listed

webapp-testing

Load when a workflow-router-selected owner workflow needs one-off local web app inspection with Playwright, screenshots, console logs, or UI issue reproduction against a dev server; use e2e-testing for durable suites.

1 Updated yesterday
JasonxzWen
Testing & QA Listed

browser-qa

Drive a real browser (Playwright) to validate user flows end-to-end — click buttons, fill forms, assert on rendered output, screenshot the moment a step breaks. Use when the user says "test this flow", "run the e2e tests", "verify the signup works", "qa my app", "does the checkout work", or asks Claude to confirm a UI change actually behaves correctly in a browser. Closes the gap between "code compiles" and "user flow works".

0 Updated 2 days ago
ashishkumar14
Testing & QA Listed

browser-qa

Drive a real browser (Playwright) to validate user flows end-to-end — click buttons, fill forms, assert on rendered output, screenshot the moment a step breaks. Use when the user says "test this flow", "run the e2e tests", "verify the signup works", "qa my app", "does the checkout work", or asks Claude to confirm a UI change actually behaves correctly in a browser. Closes the gap between "code compiles" and "user flow works".

0 Updated 2 days ago
ak-ship