fix(allure-cypress): don't reset spec context on duplicate cypress_run_start#1503
Open
todti wants to merge 4 commits into
Open
fix(allure-cypress): don't reset spec context on duplicate cypress_run_start#1503todti wants to merge 4 commits into
todti wants to merge 4 commits into
Conversation
…n_start When a spec navigates to a cross-origin URL via cy.visit, Cypress can re-initialise the browser-side support code in the secondary origin context. If the Allure env is not yet present there, initializeAllure() re-registers Mocha event listeners and the Mocha runner fires another "start" event, which enqueues a second cypress_run_start message for the same spec path. Previously #startRun always called #initializeSpecContext, throwing away the live context and all accumulated test state. This left in-progress tests without a corresponding stop message, resulting in duplicate or pending/skipped result files in the Allure report even though the tests actually passed in Cypress. Fix: skip re-initialisation when the context already exists. In cypress open the spec context is deleted by endSpec before the user can trigger a re-run, so the guard does not affect that mode. Fixes: #1329
todti
force-pushed
the
fix/cypress-double-run-start
branch
from
3c23fa9 to
20b2d8b
Compare
…start guard Add 10 more targeted unit tests grouped by concern: - context identity: same object, idempotent across many duplicates, videoScope and suite scopes preserved, mid-batch duplicate handled correctly - test results: exactly the expected results are written, no phantom pending results created - spec path isolation: duplicate for spec A does not touch spec B - reportFinalAllureCypressSpecMessages: endSpec not called in non-interactive mode, called in interactive mode - interactive re-run: fresh context and new videoScope after endSpec The two tests that drive the full test lifecycle (cypress_test_start → end) need several filesystem/env helpers to be stubbed out; a vi.mock at the top of the file provides lightweight stand-ins so the reporter under test can call #addNewTestResult without hitting getProjectName() etc. at call time.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Closes #1329.
When a Cypress spec uses
cy.visitto navigate to multiple URLs (especially cross-origin), Allure reports some tests as skipped / pending even though they passed in Cypress. Extra result files with pending content also appear.Root cause
The bug lives in
AllureCypress#startRun.When a spec triggers a cross-origin navigation, Cypress can re-initialise the browser-side support code in the secondary origin context. If
Cypress.env("allure")is absent there,initializeAllure()runs again, re-registers Mocha event listeners, and the Mocha runner emits another"start"event. This enqueues a secondcypress_run_startmessage for the same spec path while the first context is still live.Previously
#startRununconditionally called#initializeSpecContext, which overwrites the existingSpecContextwith a fresh empty one. All in-progress test state (open scopes, test UUID, suite names) is lost. Subsequent lifecycle messages (cypress_test_end,cypress_suite_end) that arrive after the reset are applied to the new empty context, and any tests that were already started never receive a proper stop message — leaving them inStage.RUNNING, which Allure renders as skipped/pending.Fix
Skip re-initialisation when the context for the spec path already exists:
cypress open(interactive) is unaffected. When the user re-runs a spec,endSpechas already deleted the context before the nextcypress_run_startarrives, so the guard evaluates tofalseand a fresh context is created as before.Testing
Two new unit tests in
doubleRunStart.test.ts:preserves spec context when cypress_run_start is received a second time— confirms the context object is not replaced when a duplicate message arrives mid-run. This test fails on the unpatched code and passes with the fix, acting as a regression guard.creates a fresh context for a spec that has already finished (interactive re-run)— confirms the interactive re-run path still works: afterendSpecremoves the context, a newcypress_run_startcorrectly creates a fresh one.