Skip to content
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

delay throw of TestRecordingMismatchException until _session is accessed #18944

Merged

Conversation

christothes
Copy link
Member

For scenarios where a recorded test wants to conditionally Assert.Ignore during Setup, this deferral of throwing TestRecordingMismatchException allows these tests to avoid having to create an empty test recording file.

@@ -51,7 +51,7 @@ public TestRecording(RecordedTestMode mode, string sessionFile, RecordedTestSani
}
catch (Exception ex) when (ex is FileNotFoundException || ex is DirectoryNotFoundException)
{
throw new TestRecordingMismatchException(ex.Message, ex);
_mismatchException = new TestRecordingMismatchException(ex.Message, ex);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we call load in the Session getter instead?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like it.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm, actually there is one scenario where this doesn't work. HasRequests needs to not trigger Load but also be accurate after the ctor runs. This change would make that tricky.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

HasRequests is only used during recording so it might be okayish not to trigger load in it are return false if nothing is loaded.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Although it happens to be true today, I'd be concerned that it could cause an issue if anyone tried to rely on HasRequests for any other reason.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But in the current implementation, it also returns the wrong value when there is no Session loaded. In theory, it should throw.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't false still correct in that case? Perhaps we should add an additional SessionLoaded bool so that one could get the full picture if that is what is intended? I'm not sure that having to wrap HasRequests in a try/catch is better.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, maybe. I just don't like relying on catching and suppressing exceptions.

christothes and others added 2 commits February 24, 2021 08:37
Co-authored-by: Pavel Krymets <pavel@krymets.com>
Co-authored-by: Pavel Krymets <pavel@krymets.com>
@christothes christothes enabled auto-merge (squash) February 24, 2021 14:39
@christothes christothes merged commit 349071e into Azure:master Feb 24, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants