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 tests for search top anomaly results API #325

Merged
merged 9 commits into from
Dec 6, 2021

Conversation

ohltyler
Copy link
Member

@ohltyler ohltyler commented Nov 23, 2021

Description

Add unit and integ tests for search top anomaly results API. Meets the jacoco coverage bar for all classes added as part of the API, removed from the exclusion list in build.gradle.

Check List

  • Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

@ohltyler ohltyler requested a review from a team November 23, 2021 23:21
@codecov-commenter
Copy link

codecov-commenter commented Nov 24, 2021

Codecov Report

Merging #325 (f1befd1) into main (ac69c3e) will increase coverage by 1.83%.
The diff coverage is 30.00%.

Impacted file tree graph

@@             Coverage Diff              @@
##               main     #325      +/-   ##
============================================
+ Coverage     75.87%   77.70%   +1.83%     
- Complexity     3950     4020      +70     
============================================
  Files           295      295              
  Lines         17182    17188       +6     
  Branches       1812     1816       +4     
============================================
+ Hits          13036    13356     +320     
+ Misses         3315     2987     -328     
- Partials        831      845      +14     
Flag Coverage Δ
plugin 77.70% <30.00%> (+1.83%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
...a/org/opensearch/ad/model/AnomalyResultBucket.java 80.00% <12.50%> (+80.00%) ⬆️
...ch/ad/transport/SearchTopAnomalyResultRequest.java 90.90% <100.00%> (+90.90%) ⬆️
...ansport/SearchTopAnomalyResultTransportAction.java 78.14% <100.00%> (+71.03%) ⬆️
.../transport/SearchAnomalyResultTransportAction.java 20.22% <0.00%> (-1.76%) ⬇️
...opensearch/ad/indices/AnomalyDetectionIndices.java 68.35% <0.00%> (-0.19%) ⬇️
.../java/org/opensearch/ad/model/AnomalyDetector.java 89.61% <0.00%> (+0.38%) ⬆️
...ain/java/org/opensearch/ad/task/ADTaskManager.java 76.60% <0.00%> (+1.58%) ⬆️
...java/org/opensearch/ad/task/ADBatchTaskRunner.java 77.96% <0.00%> (+3.03%) ⬆️
...ansport/handler/AnomalyResultBulkIndexHandler.java 70.96% <0.00%> (+3.22%) ⬆️
...port/SearchAnomalyDetectorInfoTransportAction.java 64.44% <0.00%> (+8.88%) ⬆️
... and 6 more

@amitgalitz
Copy link
Member

Are you planning on adding any integration tests with security

@ohltyler
Copy link
Member Author

Are you planning on adding any integration tests with security

Not as part of this PR. Seems there is a lot of missing API tests for security so seems it would be beneficial to do all of these together as a separate effort.

if (indexExists(CommonName.ANOMALY_RESULT_INDEX_ALIAS)) {
deleteIndex(CommonName.ANOMALY_RESULT_INDEX_ALIAS);
}
TestHelpers.createEmptyAnomalyResultIndex(client());
Copy link
Collaborator

@ylwu-amzn ylwu-amzn Dec 2, 2021

Choose a reason for hiding this comment

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

Seems this is not the normal process from user's perspective. We don't allow user to create default AD result index directly. Actually ANOMALY_RESULT_INDEX_ALIAS is alias not index.
How about change to run historical analysis to create AD result index, then search top anomaly result?

Copy link
Member Author

Choose a reason for hiding this comment

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

The purpose of this test was about having the index exist, but not return any results, so I just create the empty index so the API can query it, but still return empty results. Because this API doesn't interact with anything other than reading the results index, I still think this is ok. Same strategy is used in the below tests, as well as the existing search results tests.

I still prefer this than to run a historical analysis, so as to keep the test more lightweight, faster, and not increase the chances of it becoming flaky. Let me know if you still have concerns.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Got it. Sounds good.
Another way to generate an empty default result index is run historical analysis on a short period (so it can run quickly), then delete all results with delete result REST API. But like you said, these steps will make the test heavier and more flaky likely.

@ohltyler ohltyler merged commit e5294e6 into opensearch-project:main Dec 6, 2021
@ohltyler ohltyler deleted the multi-category-tests branch December 6, 2021 22:51
ylwu-amzn pushed a commit to ylwu-amzn/anomaly-detection-2 that referenced this pull request Jan 11, 2022
ylwu-amzn pushed a commit that referenced this pull request Jan 12, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants