-
Notifications
You must be signed in to change notification settings - Fork 879
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 HttpClientTestOptions #3714
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.
Nice 👍
import org.junit.jupiter.api.condition.DisabledIfSystemProperty; | ||
import org.junit.jupiter.params.ParameterizedTest; | ||
import org.junit.jupiter.params.provider.ValueSource; | ||
|
||
@TestInstance(TestInstance.Lifecycle.PER_CLASS) |
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.
will this affect subclasses? will that be less obvious compared to making options
below static?
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.
This is a good question, I'll confirm it but I would expect it to, most jupiter functionality goes through hierarchy. I don't think I can use the subclass configure
pattern (or any pattern I can think of) if static
, especially because the @BeforeAll
method must be static if this isn't here.
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.
Confirmed that it's respected by subclasses. Though I did come with another pattern using an extension, will play with it in a followup (if I can ever merge past the GwtTest failure :P)
…nstrumentation into httpclienttestoptions
…nstrumentation into httpclienttestoptions
…nstrumentation into httpclienttestoptions
…nstrumentation into httpclienttestoptions
We currently have many protected methods to tweak test behavior, but it can be hard to understand what options we have or what the defaults are. I think having all options grouped makes it easier to understand how to configure the test - a big reason for this is to simplify the spock bridge.
I just copied the options as is for now, but I think we can iterate to improve more - I find the knobs now to be confusing on what they control, some are semantic and control multiple tests, many just control a single test, some have different names then the test itself, etc. I also really don't like how many subclasses use the URL 192.0.2.3 as a proxy for what test they are running on to reconfigure the test. So I have some ideas about maybe having an enum corresponding to each test, or similar which will follow up with eventually.
Also if this approach looks fine, will follow up with a PR to migrate the remaining tests.