-
-
Notifications
You must be signed in to change notification settings - Fork 8.6k
[dotnet] Improve the debugging experience of tests #14755
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
Closed
RenderMichael
wants to merge
4
commits into
SeleniumHQ:trunk
from
RenderMichael:dotnet-test-debugging
Closed
Changes from all commits
Commits
Show all changes
4 commits
Select commit
Hold shift + click to select a range
a963d6f
[dotnet] Improve the debugging experience of tests
RenderMichael 8f9b75e
Merge branch 'trunk' into dotnet-test-debugging
RenderMichael def2d56
remove unnecessary disposal
RenderMichael 18d7795
Merge branch 'trunk' into dotnet-test-debugging
RenderMichael File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
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.
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.
So smart for test project. I vote for keeping simplicity, rather than being technically perfect.
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.
I realized we don't actually need to dispose the HTTP response, since we are disposing the client. I made it a little simpler, do you think this is acceptable?
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.
We have a lot of try/catch in codebase, how this one affects your debugging experience?
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.
I am not sure if I have something mis-configured, but the webserver
Stopmethod always throws an exception for me, as shown in the PR description. This is something which causes a debugger break every time I am running tests.It would be nice to avoid the debugger breaking on other exceptions which are well-handled, such as
Runfiles.Create(). However, those are in synchronous methods, and there is no nice way to get that to happen.Luckily, the quit method is an asynchronous operation and .NET 8 has an
awaitmodifier which avoids throwing the exception.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.
In my opinion, this is a simplification. It requires extracting a method only because
Stopis currently synchronous. Would it be better to makeStopasync, and propagate that out to the callers? It would not be more complex, and it would avoid doing sync-over-async where it is not necessaryThere 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.
It throws on my end, but my debugger doesn't hit it. If making
Stop()method asynchronous will help you, then it is better. Thanks.