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.
[fix] Fix TestCaseStart/Stop events dropped for data-driven tests with shared TestCase.Id #16033
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. Weβll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Uh oh!
There was an error while loading. Please reload this page.
[fix] Fix TestCaseStart/Stop events dropped for data-driven tests with shared TestCase.Id #16033
Changes from all commits
94c512e9a7b32d83d3cc0606a688File filter
Filter by extension
Conversations
Uh oh!
There was an error while loading. Please reload this page.
Jump to
Uh oh!
There was an error while loading. Please reload this page.
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[Parallel Execution & Scheduling Safety] β Broad suppression edge case with
_testCaseEndCalledSetThe
_testCaseEndCalledSetguard works correctly when all rows in a nested data-driven test consistently callRecordEnd(or consistently don't). However, the suppression is ID-scoped rather than per-call, which means it can produce an incorrect outcome if an adapter's behavior is inconsistent across rows that share the sameTestCase.Id:Row2 relied on the
RecordResultsafety-net (itsRecordEndwas never called), but the safety-net was suppressed because row1 had already calledRecordEnd.Impact assessment: This is theoretical β real adapters uniformly either call
RecordEndper row or don't. A per-call counter for "ends already sent" isn't feasible without a per-invocation identifier since all rows share the sameGuid. The current approach is the best achievable given the API surface.Suggestion: Add a comment near
_testCaseEndCalledSetstating this known limitation explicitly: that the guard assumes adapters applyRecordEnduniformly across all rows sharing the same ID. This documents the design intent for future readers.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point. I've added a
<para>block to the_testCaseEndCalledSetXML doc comment documenting this known limitation β that suppression is ID-scoped and assumes adapters applyRecordEnduniformly across all rows sharing the same ID.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[Parallel Execution & Scheduling Safety] β Potential count under-run in nested +
RecordResultscenarioSendTestCaseEndis called from two places:RecordEnd(explicit notification from the adapter)RecordResultβ as a safety net "in caseRecordEndwas not called" (line ~99)With the old
HashSetsemantics the safety net was harmless: onceRecordEndremoved the ID the subsequentRecordResultβSendTestCaseEndcall was a no-op.With the new reference-counting semantics the safety net consumes a count slot. Consider the nested pattern where the parent and a row share the same
Guidand the adapter also callsRecordResultper row (which is the normal adapter contract):Result: 3 Starts, 3 Ends β but the parent's
TestCaseEndis dropped and row1 receives a spurious extraTestCaseEnd.The new test
RecordStartAndRecordEndShouldSendEventsForNestedDataDrivenTestsWithSameIddeliberately omitsRecordResultcalls, so this path is not exercised.Suggested mitigation: Add a test covering
Start(parent) β Start(row1) β End(row1) β Result(row1) β End(parent)to confirm the expected outcome and document whether adapters are expected to callRecordResultfor individual rows in a nested scenario. If they are, the safety-net call inRecordResultmay need to be guarded so it only fires when count is exactly 1 (i.e., the last in-progress context).There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch β the safety-net was indeed consuming a count slot that belonged to the parent.
Fix applied: added
_testCaseEndCalledSet(aHashSet<Guid>) alongside the existing reference-count map.RecordEnd: adds the test case ID to_testCaseEndCalledSetbefore sending the End event. Removes it when the count reaches zero (test fully complete).RecordResultsafety-net: now only fires ifcount > 0and the ID is not in_testCaseEndCalledSet. Once anyRecordEndis called for an ID, subsequentRecordResultcalls for that ID are no-ops until the ID is fully resolved.New test added:
RecordResultShouldNotSendSpuriousTestCaseEndForParentInNestedDataDrivenScenariodirectly tests theStart(parent) β Start(row1) β End(row1) β Result(row1) β End(parent)pattern and asserts exactly 2SendTestCaseEndcalls (not 3). All 648 unit tests pass.Uh oh!
There was an error while loading. Please reload this page.