Skip to content

Conversation

@nik9000
Copy link
Member

@nik9000 nik9000 commented Dec 13, 2016

Continue consolidating XContentParser construction in tests as a prerequisite to #22003

@nik9000 nik9000 added review >test Issues or PRs that are addressing/adding tests v5.2.0 v6.0.0-alpha1 labels Dec 13, 2016
Copy link
Contributor

@imotov imotov left a comment

Choose a reason for hiding this comment

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

LGTM in general, added a couple of optional suggestions.

Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe we should rename this class into AbstractYamlParserTestCase then?

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'll rename!

Copy link
Contributor

Choose a reason for hiding this comment

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

I am just wondering did you consider passing xContent type as a parameter here instead of overloading it on the suite level? I feel like it might provide more flexibility.

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 have a feeling I'm going to have a few more iterations of this as I do more centralizing. I'll stick with what I have for now and keep an open mind to that as I go. I'm not sure that we need the flexibility but the specificity might be nice....

Copy link
Member

@javanna javanna left a comment

Choose a reason for hiding this comment

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

I have one objection, sorry @nik9000 ! We plan on removing content type auto-detection at some point (see #19388), which is going to be a big job. This PR replaces all the explicit parser creation code with auto-detection which will make it even harder to remove in the future. Why do we have to auto-detect when we exactly know the content type? I am tempted to deprecate those auto-detection methods cause we end up using them everywhere for no reason. I think we should rather pass around the known XContentType.

Moves more parser creation in tests to the `createParser` methods
in `ESTestCase`.
@nik9000
Copy link
Member Author

nik9000 commented Dec 13, 2016

We plan on removing content type auto-detection at some point (see #19388), which is going to be a big job.

Oh boy! Ok. I'll go the other way....

@nik9000 nik9000 force-pushed the test_parser_build_1 branch from e8201a3 to 917a6f9 Compare December 13, 2016 21:29
@nik9000
Copy link
Member Author

nik9000 commented Dec 13, 2016

@javanna, you caught me mid rebase. I did what you asked but it looks like I forgot to undo my rebase. So you get rebased commits. Can you have a look?

@nik9000
Copy link
Member Author

nik9000 commented Dec 13, 2016

I'm still running all the tests. I expect I'll find a few things and push fixes but you get the idea.

@javanna
Copy link
Member

javanna commented Dec 13, 2016

looks good @nik9000 thanks a lot, that is what I meant.

@nik9000 nik9000 changed the title Continue consolidating XContententParser construction in tests Continue consolidating XContentParser construction in tests Dec 13, 2016
@nik9000 nik9000 merged commit 872984d into elastic:master Dec 13, 2016
nik9000 added a commit that referenced this pull request Dec 13, 2016
Consolidate more parser creation in tests

Moves more parser creation in tests to the `createParser` methods
in `ESTestCase`.
@nik9000
Copy link
Member Author

nik9000 commented Dec 13, 2016

Thanks for reviewing everyone!

master: 872984d
5.x: 4f65d87

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 v5.2.0 v6.0.0-alpha1

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants