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 HttpClientTestOptions #3714

Merged
merged 6 commits into from
Aug 2, 2021

Conversation

anuraaga
Copy link
Contributor

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.

Copy link
Member

@mateuszrzeszutek mateuszrzeszutek left a 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)
Copy link
Member

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?

Copy link
Contributor Author

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.

Copy link
Contributor Author

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)

Anuraag Agrawal added 4 commits July 30, 2021 13:23
@anuraaga anuraaga merged commit 40aad45 into open-telemetry:main Aug 2, 2021
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.

4 participants