-
Notifications
You must be signed in to change notification settings - Fork 8.1k
Replace HttpListener Response Tests with WebListener #5540
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
Replace HttpListener Response Tests with WebListener #5540
Conversation
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.
Is it ok to use explicit port?
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 this case, the port is not used. The header is echoed back like so:
Link: <http://localhost:8080/PowerShell?test=linkheader&maxlinks=5&linknumber=1>; rel="self"
Link: <http://localhost:8080/PowerShell?test=linkheader&maxlinks=5&linknumber=2>; rel="next"
Link: <http://localhost:8080/PowerShell?test=linkheader&maxlinks=5&linknumber=5>; rel="last"
and then the test is to ensure the RelationLink.Count is 3 and the the exact urls are provided. These URLs could be anything for this test, but since the linkheader API still lives on HttpListener and not WebListener, I kept the URLs as is so they can actually be useful if you manually repro the test.
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.
Could you please explain why we want to remove these tests?
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 did in the PR description.
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 can remove the BeforeAll .
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.
fixed
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.
Please remove the extra line.
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.
fixed
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 never use the formatting.
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.
Do i really need to have this all on one line where you have to scroll for an eternity to see it?
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 believe we use the pattern:
if (Request.Query.TryGetValue("statuscode", out statusCodes) &&
Int32.TryParse(statusCodes.FirstOrDefault(), out statusCode))
{
...
}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.
fixed
|
@markekraus Could you please rebase to pass CI Appveyor? |
|
@iSazonov Rebase wont help this one. It already picked up #5554 in the last empty commit to re-run CI. The problem now is fail in #5567 (which is actually a dup of an older issue where I noted the same behavior randomly happening). I will rebase anyway in hopes that the WMF links are working now and we don't find some other transient test issue in the feature tests. |
f256997 to
26d4ebe
Compare
|
The test run got a hard failure: @markekraus I'm not sure how the |
|
Is there some reason we don't run the feature tests on every PR? I run into so many CI fails because most of the web cmdlet tests are gated behind the feature tag. Changes made in other PR's that affect the Feature tests are not being properly vetted. In the past even my own PRs have been approved with broken feature tests. |
|
Feature test run takes more time and not every PR needs the full feature test run, so it's not on by default. |
@dantraMSFT Have you any ideas why the PSEtwLog is activated from WebListener? |
|
PSEtwLog is not being activated from WebListener... indicates that the Line 960 in 7dce411
WebListener is not being run at that point. and the compile appears to be successful This is failing sometime after |
|
The root cause of the loading failure was that one of our team members uploaded a |
|
thanks. This PR shouldn't have anything outstanding on it. |
* Add Response Controller * [Feature] Replace HttpListener Response tests with WebListener
* Add Response Controller * [Feature] Replace HttpListener Response tests with WebListener
ref #5464 , #2504, #3267
HttpListener"response" tests withWebListener/Response/test toWebListenerHtmlWebResponseObjecttests as HTML parsing will no longer be done by the web cmdlets Webcmdlets should parse the <html><head><meta charset="foo"> attribute for the correct encoding if not in http header #3267 (comment)`nThis should alleviate some of the macOS HttpListener related failures.