Replace HttpListener Response Tests with WebListener#5540
Replace HttpListener Response Tests with WebListener#5540adityapatwardhan merged 4 commits intoPowerShell:masterfrom
Conversation
There was a problem hiding this comment.
Is it ok to use explicit port?
There was a problem hiding this comment.
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.
Could you please explain why we want to remove these tests?
There was a problem hiding this comment.
I did in the PR description.
There was a problem hiding this comment.
We can remove the BeforeAll .
There was a problem hiding this comment.
Please remove the extra line.
There was a problem hiding this comment.
We never use the formatting.
There was a problem hiding this comment.
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.
I believe we use the pattern:
if (Request.Query.TryGetValue("statuscode", out statusCodes) &&
Int32.TryParse(statusCodes.FirstOrDefault(), out statusCode))
{
...
}|
@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.