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

Removing explicit SearchResponse usages in tests #102008

Conversation

pmpailis
Copy link
Contributor

@pmpailis pmpailis commented Nov 10, 2023

Tests covered in this PR:

  • org.elasticsearch.xpack.enrich.EnrichPolicyRunnerTests
  • org.elasticsearch.index.engine.frozen.FrozenIndexIT
  • org.elasticsearch.index.engine.frozen.FrozenIndexTests

@elasticsearchmachine elasticsearchmachine added needs:triage Requires assignment of a team area label v8.12.0 labels Nov 10, 2023
Copy link
Member

@original-brownbear original-brownbear left a comment

Choose a reason for hiding this comment

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

Lets fix the assertNoFailures blocks here and back out that one tricky change, otherwise this is perfect, thanks!

SearchResponse resp = prepareSearch().setPreference(null).setPointInTime(new PointInTimeBuilder(pitId)).get();
assertNoFailures(resp);
assertHitCount(resp, 0);
assertResponse(prepareSearch().setPreference(null).setPointInTime(new PointInTimeBuilder(pitId)), searchResponse -> {
Copy link
Member

Choose a reason for hiding this comment

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

This case can use assertNoFailuresAndResponse to save us the assertNoFailures(searchResponse);, lets do that in all the spots we have here to keep the growing code size from this effort in check (at least a little)

}
searchResponse = client().prepareSearchScroll(searchResponse.getScrollId()).setScroll(TimeValue.timeValueMinutes(1)).get();
Copy link
Member

Choose a reason for hiding this comment

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

This isn't correct is it? Aren't we overwriting values for searchResponse without releasing them here? Either way, maybe leave this one out from this changeset, we can deal with it later on, it's a bit of a non-standard case?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah, you're right. I've slightly updated this if you want to take a look, otherwise we can skip and revisit later on as suggested :)

@pmpailis pmpailis added >test Issues or PRs that are addressing/adding tests :Search/Search Search-related issues that do not fall into other categories Team:Search Meta label for search team auto-merge Automatically merge pull request when CI checks pass (NB doesn't wait for reviews!) and removed needs:triage Requires assignment of a team area label labels Nov 10, 2023
@elasticsearchmachine
Copy link
Collaborator

Pinging @elastic/es-search (Team:Search)

@pmpailis pmpailis removed the auto-merge Automatically merge pull request when CI checks pass (NB doesn't wait for reviews!) label Nov 10, 2023
Copy link
Member

@original-brownbear original-brownbear left a comment

Choose a reason for hiding this comment

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

Two tiny nits and I think I still may prefer not doing the bigger change at the bottom, this looks super verbose, the test was very hard to understand before and is even harder to read now. Maybe just back that out and not mess with it right now?
We just need to improve tooling a little her eI think :)

assertHitCount(resp, 0);
assertNoFailuresAndResponse(
prepareSearch().setPreference(null).setPointInTime(new PointInTimeBuilder(pitId)),
searchResponse -> {
Copy link
Member

Choose a reason for hiding this comment

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

NIT: No need for the curly braces here :)

assertHitCount(resp, numDocs);
assertNoFailuresAndResponse(
prepareSearch().setPreference(null).setPointInTime(new PointInTimeBuilder(pitId)),
searchResponse -> {
Copy link
Member

Choose a reason for hiding this comment

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

NIT No need for curly braces

shard = indexService.getShard(i);
engine = IndexShardTestCase.getEngine(shard);
assertFalse(((FrozenEngine) engine).isReaderOpen());
scrollResponse = client().prepareSearch()
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 actually want to adjust this one here, why don't we start from the standard assertResponse approach here. why use a tricky try-finally and deviatee from our usual approach?

@pmpailis
Copy link
Contributor Author

Two tiny nits and I think I still may prefer not doing the bigger change at the bottom, this looks super verbose, the test was very hard to understand before and is even harder to read now. Maybe just back that out and not mess with it right now? We just need to improve tooling a little her eI think :)

Yeah makes sense. I wasn't too keen either in how it turned out. Reverted and we can go back at a later time.

).actionGet();
assertEquals(0L, routingSearchResponse.getHits().getTotalHits().value);
final int targetIdx = idx;
assertResponse(
Copy link
Member

Choose a reason for hiding this comment

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

assertHitCount, this is only checking the hits count.

assertThat(sourceDocMap.get("field5"), is(equalTo("value5")));
}
);
assertResponse(
Copy link
Member

Choose a reason for hiding this comment

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

assertHitCount only checking hits count

Comment on lines 2014 to 2021
assertResponse(
client().search(
new SearchRequest(".enrich-test1").source(SearchSourceBuilder.searchSource().query(QueryBuilders.matchAllQuery()))
),
allEnrichDocs -> {
assertThat(allEnrichDocs.getHits().getTotalHits().value, equalTo(2L));
}
);
Copy link
Member

Choose a reason for hiding this comment

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

assertHitCount only checking hits count

}

public void testEnrichObjectField() {
public void testEnrichObjectField() throws ExecutionException, InterruptedException {
Copy link
Member

Choose a reason for hiding this comment

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

its a test, so it could just be throws Exception

Comment on lines 337 to 340
assertNoFailuresAndResponse(
prepareSearch().setPreference(null).setPointInTime(new PointInTimeBuilder(pitId)),
searchResponse -> assertHitCount(searchResponse, 0)
);
Copy link
Member

Choose a reason for hiding this comment

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

assertHitCount only checking hits count. If we need to double check for no failures, we should have a asserNoFailuresAndHitCount

@JVerwolf
Copy link
Contributor

@elasticmachine update branch

@pmpailis pmpailis added the auto-merge Automatically merge pull request when CI checks pass (NB doesn't wait for reviews!) label Nov 13, 2023
@pmpailis
Copy link
Contributor Author

@elasticmachine update branch

@elasticsearchmachine elasticsearchmachine merged commit ebbcb71 into elastic:main Nov 13, 2023
13 checks passed
@pmpailis pmpailis deleted the fix/remove-explicit-search-response-test branch November 13, 2023 12:53
davidkyle pushed a commit to davidkyle/elasticsearch that referenced this pull request Nov 13, 2023
Tests covered in this PR: *
`org.elasticsearch.xpack.enrich.EnrichPolicyRunnerTests` *
`org.elasticsearch.index.engine.frozen.FrozenIndexIT` *
`org.elasticsearch.index.engine.frozen.FrozenIndexTests`
Copy link
Member

@original-brownbear original-brownbear left a comment

Choose a reason for hiding this comment

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

LGTM

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
auto-merge Automatically merge pull request when CI checks pass (NB doesn't wait for reviews!) :Search/Search Search-related issues that do not fall into other categories Team:Search Meta label for search team >test Issues or PRs that are addressing/adding tests v8.12.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants