Add a highlighter unit test base class #85719
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
romseygeek
added
>test
|
Pinging @elastic/es-search (Team:Search) |
|
I've added one very basic unified highlighter test to this, but I think it might be worth trying to migrate some of our existing highlighter integration tests to use this base class instead. |
mayya-sharipova
approved these changes
Apr 6, 2022
There was a problem hiding this comment.
@romseygeek Thanks Alan, this looks very nice and simplify our highlight tests a lot.
| SearchSourceBuilder search = new SearchSourceBuilder().query(QueryBuilders.termQuery("field", "some")) | ||
| .highlighter(new HighlightBuilder().field("field")); | ||
|
|
||
| Map<String, HighlightField> highlights = highlight(mapperService, doc, search); |
There was a problem hiding this comment.
Is it worth to have even higher level abstraction, and provide a mapping and a document as Strings to highlight method, and highlight method itself inside create MapperService and ParsedDocument?
There was a problem hiding this comment.
I did think about doing things that way, but I think this is slightly more flexible - it allows you to build mappings from XContent if you want to build something programmatically, for example. If it turns out that we're almost always using this pattern we can always add a sugar method that just takes strings.
There was a problem hiding this comment.
Thanks for explanation, Alan, makes sense.
weizijun
added a commit
to weizijun/elasticsearch
that referenced
this pull request
Apr 13, 2022
* upstream/master: (40 commits) Fix BuildTests serialization (elastic#85827) Use urgent priority for node shutdown cluster state update (elastic#85838) Remove Task classes from HLRC (elastic#85835) Remove unused migration classes (elastic#85834) Remove uses of Charset name parsing (elastic#85795) Remove legacy versioned logic for DefaultSystemMemoryInfo (elastic#85761) Expose proxy settings for GCS repositories (elastic#85785) Remove SLM classes from HLRC (elastic#85825) TSDB: fix the time_series in order collect priority (elastic#85526) Remove ILM classes from HLRC (elastic#85822) FastVectorHighlighter should use ValueFetchers to load source data (elastic#85815) Iteratively execute synchronous ingest processors (elastic#84250) Remove TransformClient from HLRC (elastic#85787) Mute XPackRestIT deprecation/10_basic/Test Deprecations (elastic#85807) Unmute Lintian packaging test (elastic#85778) Add a highlighter unit test base class (elastic#85719) Remove NIO Transport Plugin (elastic#82085) [TEST] Remove token methods from HLRC SecurityClient (elastic#85515) [Test] Use thread-safe hashSet for result collection (elastic#85653) [TEST] Mute BuildTests.testSerialization (elastic#85801) ... # Conflicts: # server/src/test/java/org/elasticsearch/search/aggregations/timeseries/TimeSeriesIndexSearcherTests.java
romseygeek
added a commit
to romseygeek/elasticsearch
that referenced
this pull request
Jun 6, 2022
The vast majority of our highlighter tests are integration or rest tests, which exercise the full ES stack but take a long time to run and are difficult to debug. We have a few unit tests but they are testing very low-level behaviour, and don't interact with the fetch phase or hit contexts. This commit adds a new HighlighterTestCase base class with some helper methods that should fill the gap between these two sets of tests. It includes a method that takes a MapperService, ParsedDocument and SearchSourceBuilder, and then runs the appropriate highlighter fetch subphase over the resulting hit.
romseygeek
added a commit
that referenced
this pull request
Jun 7, 2022
The vast majority of our highlighter tests are integration or rest tests, which exercise the full ES stack but take a long time to run and are difficult to debug. We have a few unit tests but they are testing very low-level behaviour, and don't interact with the fetch phase or hit contexts. This commit adds a new HighlighterTestCase base class with some helper methods that should fill the gap between these two sets of tests. It includes a method that takes a MapperService, ParsedDocument and SearchSourceBuilder, and then runs the appropriate highlighter fetch subphase over the resulting hit.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The vast majority of our highlighter tests are integration or rest tests, which exercise
the full ES stack but take a long time to run and are difficult to debug. We have a few
unit tests but they are testing very low-level behaviour, and don't interact with the fetch
phase or hit contexts. This commit adds a new HighlighterTestCase base class with some
helper methods that should fill the gap between these two sets of tests. It includes a
method that takes a MapperService, ParsedDocument and SearchSourceBuilder, and then
runs the appropriate highlighter fetch subphase over the resulting hit.