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

Add tests for containsHeaderString #1238

Merged
merged 8 commits into from
Mar 28, 2024

Conversation

jim-krueger
Copy link
Contributor

@jim-krueger jim-krueger commented Mar 18, 2024

Addresses #1227

Awaiting formal testing.

@jim-krueger jim-krueger self-assigned this Mar 18, 2024
@jim-krueger jim-krueger force-pushed the 1227-TCK-containsHeaderString branch 2 times, most recently from 7a89e78 to a3a65b2 Compare March 20, 2024 13:15
Copy link
Contributor

@jamezp jamezp left a comment

Choose a reason for hiding this comment

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

Should we also be testing the Container*Context and HttpHeaders as well since they both include these methods too?

@jim-krueger jim-krueger force-pushed the 1227-TCK-containsHeaderString branch 3 times, most recently from 7c2aeb2 to 4c2d374 Compare March 20, 2024 22:55
@jim-krueger jim-krueger force-pushed the 1227-TCK-containsHeaderString branch 3 times, most recently from 2df867c to c504dde Compare March 22, 2024 15:21
protected void checkFilterContext(ClientRequestContext context) throws Fault {
assertTrue(context.containsHeaderString("header1", "value"::equalsIgnoreCase));
assertTrue(context.containsHeaderString("HEADER1", ",", "value2"::equals));
//Incorrect separator character
Copy link
Contributor

Choose a reason for hiding this comment

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

IMHO a TCK test should only test for the existence of a given rule, not for the absence of particular bugs.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think this test is valid since it confirms that the value of the separator character parameter is actually used and taken into consideration by the impl.

Copy link
Contributor

Choose a reason for hiding this comment

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

"Incorrect separator character" does not imply that. Checking for correct pickup of separator is implied in line 879 already.

Copy link
Contributor Author

@jim-krueger jim-krueger Mar 24, 2024

Choose a reason for hiding this comment

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

Line 879 only proves that the line separator parameter can be included in the invocation, but not that it is actually used by the impl. The impl could be ignoring that parameter and accepting any separator character as valid. This is why the "incorrect separator character" test is good. It tests that the impl is using the the separator parameter and that it is checking it specifically and not just allowing any separator.

Copy link
Contributor

Choose a reason for hiding this comment

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

I wonder if instead there could be a test that actively checks usage of the separator, and positively comments about that.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I see your point, I'm just not sure there is a way to ensure that the separator parameter is actually being used without having at lease one test that expects failure in that respect.

Copy link
Contributor

Choose a reason for hiding this comment

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

To me the test makes sense. If you split with the wrong separator (so you don't really split) then the assertion is false.

Copy link
Contributor

Choose a reason for hiding this comment

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

That is correct, but just because using the wrong separator fails the test does not imply that using the correct separator passes the test.

@jim-krueger jim-krueger force-pushed the 1227-TCK-containsHeaderString branch 2 times, most recently from 5527020 to 585b81f Compare March 25, 2024 00:32
@spericas spericas requested review from jamezp, jansupol and mkarg March 25, 2024 13:26
@spericas spericas added this to the 4.0 milestone Mar 25, 2024
@jim-krueger jim-krueger force-pushed the 1227-TCK-containsHeaderString branch from 585b81f to 73d7cbc Compare March 25, 2024 17:18
@jim-krueger jim-krueger force-pushed the 1227-TCK-containsHeaderString branch from 73d7cbc to 78208ee Compare March 25, 2024 18:30
jamezp
jamezp previously approved these changes Mar 25, 2024
Copy link
Contributor

@jamezp jamezp left a comment

Choose a reason for hiding this comment

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

This looks good to me. There are a couple spots where there are some whitespace only changes, but I don't want to block this PR based on that.

@jim-krueger jim-krueger force-pushed the 1227-TCK-containsHeaderString branch from f70e010 to ac9837b Compare March 26, 2024 12:50
@spericas
Copy link
Contributor

@mkarg Your change request is now blocking this PR

Copy link
Contributor

@mkarg mkarg left a comment

Choose a reason for hiding this comment

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

I am not used to writing TCK tests, so I am not actively voting +1, but feel free to proceed anyways.

protected void checkFilterContext(ClientRequestContext context) throws Fault {
assertTrue(context.containsHeaderString("header1", "value"::equalsIgnoreCase));
assertTrue(context.containsHeaderString("HEADER1", ",", "value2"::equals));
//Incorrect separator character
Copy link
Contributor

Choose a reason for hiding this comment

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

That is correct, but just because using the wrong separator fails the test does not imply that using the correct separator passes the test.

@jim-krueger jim-krueger merged commit 273a477 into jakartaee:main Mar 28, 2024
3 checks passed
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.

5 participants