Test-drive browser JavaScript behavior with DOM fixtures, test runners, smoke tests, onload timing, selector refactors, and integration tradeoffs with Selenium or end-to-end tests.
SkillScore95Maintained
Automatic
◆QA & Test Engineering pack
Last verified 8/15/2026
What it changes
Passed 21 of 22 test cases with the skill, and 19 of 22 without it.
Without skill86%
With skill95%
Checks it passed that the model alone missed
Recommends starting with the user-visible browser behavior
Recommends recording the test runner command and its execution result
Recommends performing an integration check or functional test to ensure the real page actually invokes the JavaScript code
3 fixed18 passed either way0 still failing1 broke
Pass-rate lift
+9 pp
Tokens
-9%
Agent turns
0%
Response time
-40%
Model gemini-3.6-flashMeasured 8/15/2026v121 of 22 cases passed with skill
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 3 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 3
Prompt
When initiating a browser JavaScript feature, what aspect should be determined first before writing unit tests?
What was checked, without and with the skill
Checked
Without skill
With skill
Recommends starting with the user-visible browser behavior
Missed
Passed
case-19 · gemini-3.6-flash · 8/15/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md55 lines2 files
Browser JavaScript TDD
Use this skill when browser-side behavior needs fast feedback before or alongside end-to-end tests. Keep JavaScript unit tests focused on DOM behavior and use broader browser tests only for integration confidence.
Source Traceability
Primary source: Harry Percival, Test-Driven Development with Python, 3rd ed. Guidance is transformed and paraphrased from chapters 17, 25, and Appendix B, especially browser-based Jasmine tests, DOM fixtures, onload timing, selector refactoring, and JavaScript CI integration.
Workflow
Start with the user-visible browser behavior.
Decide what the JavaScript owns: DOM update, class toggle, client-side validation, enhancement, or integration hook.
Keep server-owned state out of client unit tests.
Choose the test boundary.
Use JavaScript unit tests for pure functions and DOM manipulation.
Use one end-to-end test when Django/server, CSS, and browser wiring must be proven together.
Do not use Selenium to exhaustively test JavaScript branches.
Build a stable DOM fixture.
Include only the markup required by the behavior.
Reset global state between tests.
Make initialization explicit instead of relying on incidental page load order.
Red/green/refactor the JavaScript.
First smoke-test the runner.
Add a failing DOM behavior test.
Implement minimal code.
Refactor selectors and initialization while tests are green.
Read browser-js-patterns.md for DOM fixtures, initialization, and CI patterns.
Decision Rules
If the behavior is DOM-local, prefer JavaScript tests.
If the risk is server-client integration, keep a small browser functional test.
If the code depends on page load timing, expose an initialization function and test it directly.
If selectors are duplicated across tests and code, introduce named selectors or data attributes deliberately.
If the test needs CSS behavior, decide whether style is truly the contract or only incidental.