-
Notifications
You must be signed in to change notification settings - Fork 269
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
Record test start/end events for data driven tests #631
Conversation
src/Adapter/MSTest.CoreAdapter/Execution/TestExecutionManager.cs
Outdated
Show resolved
Hide resolved
src/Adapter/MSTest.CoreAdapter/Execution/TestExecutionManager.cs
Outdated
Show resolved
Hide resolved
src/Adapter/MSTest.CoreAdapter/Execution/TestExecutionRecorderWrapper.cs
Show resolved
Hide resolved
CollectionAssert.AreEqual(expectedTestCaseStartList, this.frameworkHandle.TestCaseStartList); | ||
CollectionAssert.AreEqual(expectedTestCaseEndList, this.frameworkHandle.TestCaseEndList); | ||
CollectionAssert.AreEqual(expectedResultList, this.frameworkHandle.ResultsList); | ||
CollectionAssert.Contains(this.frameworkHandle.TestCaseStartList, "PassingTest"); |
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.
@jayaranigarg I added back the start/end events in TestExecutionManager. The side effect is that we now have duplicate start/end events for non-data driven tests. It's a bit odd but shouldn't effect execution because vstest ignores duplicate events. I don't think there is much I can do here because TestMethodInfo doesn't really know if the test is being executed more than once.
This is a fix for #340 so that data collectors can get start/end events for individual execution of data driven tests. Also solves to allow the custom test execution extension to run a test multiple times and get multiple start/end events.
Solving for #464 might be a better approach but seems like a much bigger change.
One side effect of this change is ClassInitialize happens before any start event gets fired. IMO this is fine, it always seemed weird that this execution would be lumped into the first test that happened to execute. This also make it so ClassInitialize is now identical to ClassCleanup which doesn't get captured.