Browser-Test Debug Command Committed
ID |
javascript.ui_test_debug_command |
Severity |
high |
Remediation Complexity |
trivial |
Remediation Risk |
low |
Remediation Effort |
low |
Resource |
Reliability |
Language |
JavaScript |
Tags |
reliability, testing |
Description
Reports a browser-test debug command left in committed code: cy.pause(), cy.debug(), page.pause(), browser.debug(), screen.debug().
Reported wherever they appear in a spec file, inside a test or not: a debug command in a helper the tests call stalls the run just the same. The chained form cy.get('#total').debug() is recognised too; a bare debug(…) is not, because it is far more often a logger.
Rationale
// Bad
it('shows the total', () => {
cy.visit('/checkout');
cy.pause();
cy.get('#total').should('have.text', '12.00');
});-
Each of these is a tool for watching a test run by hand, and none of them belongs in a run nobody is watching.
-
The pausing commands stop the test and wait for a human, so in CI the job hangs until the runner’s own limit kills it, and the report says "timed out" rather than naming the line that is waiting.
-
The printing commands dump the DOM into the log on every run, which costs nothing but buries the output that matters when a real failure has to be diagnosed.
-
Locally the command still works, so the author sees a passing test and the failure only appears in the shared pipeline, where the diagnosis is slowest.
Remediation
Remove the command. What it was doing by hand is done in a run by an assertion, or by the artefacts the runner already collects on failure.
// Good
it('shows the total', () => {
cy.visit('/checkout');
cy.get('#total').should('have.text', '12.00');
});To inspect a run interactively, use the runner’s own interactive mode or its trace viewer, neither of which is written into the spec.