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 realistic hlrc request serialization test base class and #40362

Merged
merged 8 commits into from
Apr 10, 2019

Conversation

martijnvg
Copy link
Member

change hlrc ccr request tests to use AbstractRequestTestCase base class.

This way the request classes are tested in a more realistic setting.
Note this change also adds a test dependency on xpack core module.

Similar to #39844 but then for hlrc request serialization tests.
Relates to #39745

change hlrc ccr request tests to use AbstractRequestTestCase base class.

This way the request classes are tested in a more realistic setting.
Note this change also adds a test dependency on xpack core module.

Similar to elastic#39844 but then for hlrc request serialization tests.

Relates to elastic#39745
@martijnvg martijnvg added >test Issues or PRs that are addressing/adding tests :Core/Features/Java High Level REST Client v8.0.0 v7.2.0 labels Mar 22, 2019
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-core-features

@@ -66,6 +66,9 @@ dependencies {
testCompile "org.elasticsearch:rest-api-spec:${version}"

restSpec "org.elasticsearch:rest-api-spec:${version}"
// Needed for serialization tests:
// (In order to serialize a server side class to a client side class or the other way around)
testCompile "org.elasticsearch.plugin:x-pack-core:${version}"
Copy link
Contributor

Choose a reason for hiding this comment

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

This is a test dependency but I think it's still one that we have no precedent for.
Maybe it would be better to have these tests somewhere in x-pack/qa ?

Copy link
Member Author

Choose a reason for hiding this comment

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

If these tests were integration tests then I would agree. However since these tests are unit tests, I think they should stay next to the code that these tests are testing.

Copy link
Contributor

Choose a reason for hiding this comment

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

I think a test dep on xpack is perfectly fine WRT unit tests here. I agree w/ @martijnvg but thank you for having the eagle eye @atorok and bringing this up, just because it is definitely a major dependency.

@martijnvg
Copy link
Member Author

@elasticmachine run elasticsearch-ci/2

@martijnvg martijnvg requested a review from hub-cap April 3, 2019 11:40
Copy link
Contributor

@hub-cap hub-cap left a comment

Choose a reason for hiding this comment

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

SO much cleaner. Ive left one Q about the named writables, and this is approve-worthy pending an answer there.

@@ -66,6 +66,9 @@ dependencies {
testCompile "org.elasticsearch:rest-api-spec:${version}"

restSpec "org.elasticsearch:rest-api-spec:${version}"
// Needed for serialization tests:
// (In order to serialize a server side class to a client side class or the other way around)
testCompile "org.elasticsearch.plugin:x-pack-core:${version}"
Copy link
Contributor

Choose a reason for hiding this comment

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

I think a test dep on xpack is perfectly fine WRT unit tests here. I agree w/ @martijnvg but thank you for having the eagle eye @atorok and bringing this up, just because it is definitely a major dependency.

*/
public abstract class AbstractRequestTestCase<C extends ToXContent, S> extends ESTestCase {

private static final int NUMBER_OF_TEST_RUNS = 20;
Copy link
Contributor

Choose a reason for hiding this comment

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

should this be overridable?

Copy link
Member Author

Choose a reason for hiding this comment

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

We can make it overridable. However all the other parsing tests don't do this either and have the number of tests runs also fixed to 20. So I think for now this is ok?

Copy link
Member

Choose a reason for hiding this comment

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

Do we need this? Our tests run a bazillion times a day in CI. Is 20x a bazillion buying us anything?

Copy link
Member Author

Choose a reason for hiding this comment

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

Do we need this? Our tests run a bazillion times a day in CI. Is 20x a bazillion buying us anything?

Good question. We do this in the other xcontent parsing tests too. I personally like like this during development, so that silly mistakes are caught before I merge into master. On the other hand, I can also run the tests with -Dtests.iters=N flag. Like you say we keep paying the price until these tests are no longer run in CI. So from that perspective it makes sense to remove the loop. If we do this here then we should also do this in the other xcontent parsing tests. wdyt?

Copy link
Contributor

Choose a reason for hiding this comment

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

++ im fine w/ removing. I develop using tests.iters quite typically on the hlrc unit tests.

Copy link
Member Author

Choose a reason for hiding this comment

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

I've removed the iterations in this base class and AbstractResponseTestCase: e5b1ca7

Copy link
Member

Choose a reason for hiding this comment

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

If we do this here then we should also do this in the other xcontent parsing tests. wdyt?

+1


final XContent xContent = XContentFactory.xContent(xContentType);
final XContentParser parser = xContent.createParser(
new NamedXContentRegistry(ClusterModule.getNamedXWriteables()),
Copy link
Contributor

Choose a reason for hiding this comment

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

is this the only named writeables we will need for these tests?

Copy link
Member Author

Choose a reason for hiding this comment

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

I turns out we need no named xcontents, at least for now. So I will change this to use an empty registry. I like to be careful requiring the usage of named xcontent on the hlrc side for now.

Copy link
Contributor

Choose a reason for hiding this comment

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

agree. good call.

@martijnvg martijnvg requested a review from hub-cap April 5, 2019 18:50
Copy link
Contributor

@hub-cap hub-cap left a comment

Choose a reason for hiding this comment

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

:shipit:

@martijnvg martijnvg merged commit 99ea830 into elastic:master Apr 10, 2019
martijnvg added a commit that referenced this pull request Apr 10, 2019
changed hlrc ccr request tests to use AbstractRequestTestCase base class.

This way the request classes are tested in a more realistic setting.
Note this change also adds a test dependency on xpack core module.

Similar to #39844 but then for hlrc request serialization tests.

Removed iterators from hlrc parsing tests.
Use empty xcontent registries.

Relates to #39745
gurkankaymak pushed a commit to gurkankaymak/elasticsearch that referenced this pull request May 27, 2019
…#40362)

changed hlrc ccr request tests to use AbstractRequestTestCase base class.

This way the request classes are tested in a more realistic setting.
Note this change also adds a test dependency on xpack core module.

Similar to elastic#39844 but then for hlrc request serialization tests.

Removed iterators from hlrc parsing tests.
Use empty xcontent registries.

Relates to elastic#39745
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
>test Issues or PRs that are addressing/adding tests v7.2.0 v8.0.0-alpha1
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants