-
Notifications
You must be signed in to change notification settings - Fork 24.9k
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
Add realistic hlrc request serialization test base class and #40362
Conversation
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
Pinging @elastic/es-core-features |
client/rest-high-level/build.gradle
Outdated
@@ -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}" |
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 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
?
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.
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.
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.
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.
@elasticmachine run elasticsearch-ci/2 |
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.
SO much cleaner. Ive left one Q about the named writables, and this is approve-worthy pending an answer there.
client/rest-high-level/build.gradle
Outdated
@@ -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}" |
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.
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; |
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.
should this be overridable?
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.
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?
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.
Do we need this? Our tests run a bazillion times a day in CI. Is 20x a bazillion buying us anything?
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.
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?
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.
++ im fine w/ removing. I develop using tests.iters quite typically on the hlrc unit tests.
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.
I've removed the iterations in this base class and AbstractResponseTestCase
: e5b1ca7
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.
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()), |
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.
is this the only named writeables we will need for these tests?
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.
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.
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.
agree. good call.
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.
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
…#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
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