Comprehensive aggregation REST tests

polyfractal commented 7 years ago

There are only a few REST tests that verify the body of aggregation results. We should have a more comprehensive suite of tests that check the body under a variety of conditions and options.

Metrics:

[x] Avg Aggregation (#26225)
[x] Boxplot Aggregation (#78354)
[x] Cardinality Aggregation (#26239)
[x] Extended Stats Aggregation (#26239)
[x] Geo Bounds Aggregation (#94742)
[x] Geo Centroid Aggregation (#94964)
[x] Geo_line Aggregation (#94734)
[x] Matrix stats
[x] Max Aggregation (#26225)
[x] Median absolute deviation (missing compression, I think)
[x] Min Aggregation (#26225)
[x] Percentiles Aggregation (#26266)
[x] Percentile Ranks Aggregation (#77815)
[x] Rate (#95576 )
[x] Scripted Metric Aggregation (#95632)
[x] Stats Aggregation (#26239)
[x] String stats
[x] Sum Aggregation (#26225)
[x] t-test
[x] Top hits Aggregation (#83690)
[x] Top metrics
[x] Value Count Aggregation (#26239)
[x] Weighted average (#81306))

Bucketing

[x] Adjacency Matrix Aggregation (#69440)
[x] Auto-interval histogram (#84836)
[x] Children Aggregation (#78264)
[x] Composite (https://github.com/elastic/elasticsearch/pull/94753)(Mark)
[x] Date Histogram Aggregation
[x] Date Range Aggregation (#75434)
[x] Diversified Sampler Aggregation (#77810)
[x] Filter Aggregation (#69439)
[x] Filters Aggregation (#27128)
[ ] Geo Distance Aggregation (Craig)
[x] GeoHash grid Aggregation on geo_point (#37996) (#94747)
[x] GeoTile grid Aggregation on geo_point (#37842) (#94747)
[x] GeoHex grid Aggregation on geo_point (#82924)
[x] GeoHash grid Aggregation on geo_shape (#94747)
[x] GeoTile grid Aggregation on geo_shape (#94747)
[x] GeoHex grid Aggregation on geo_shape (#94747)
[x] Global Aggregation (#71575)
[x] Histogram Aggregation (#72322)
[x] IP Range Aggregation (#75434)
[x] Missing Aggregation (#53214)
[x] Multi-terms (only basics are tested) (#94975)
[x] Nested Aggregation (#68243)
[x] Parent (#78264)
[x] Range Aggregation (expanded in #75434)
[x] Rare terms (added when the agg was added in #35718)
[x] Reverse nested Aggregation (#83874)
[x] Sampler Aggregation (#77807)
[x] Significant Terms Aggregation (more minimal than terms but the agg sees less use)
[x] Significant Text (#72727)
[x] Terms Aggregation

Pipeline

[x] Avg Bucket Aggregation #87009 #88027
[x] Bucket Script Aggregation #94749 (Nik)
[x] Bucket Selector Aggregation #91355
[x] Bucket sort #91221
[x] Cumulative cardinality #88966
[x] Cumulatve sum #88966
[x] Derivative Aggregation #91014
[x] Max Bucket Aggregation #87009 #88027
[x] Min Bucket Aggregation #87009 #88027
[x] Moving Function Aggregation #90012
[x] Moving percentiles #90569
[x] Normalize (#89629)
[x] Percentiles Bucket Aggregation #88029
[x] Serial Differencing Aggregation #86401
[x] Stats Bucket Aggregation #87006
[x] Sum Bucket Aggregation #87009 #88027

javanna commented 7 years ago

Question: do we want to have these as yaml tests so the language clients can run them too? Or shall we consider making them java tests that se the low-level REST client instead?

polyfractal commented 7 years ago

I was targeting the yaml tests so that clients could also run them, figured that would provide the widest benefit to new tests (since basically none of the clients do any body testing at all, it may smoke out some issues). And yaml tests are sometimes easier to write :)

But I could be convinced either way. What do you think?

javanna commented 7 years ago

I am fine with moving forward with yaml tests, I don't have a strong opinion, I just wanted to make sure that we consider writing java tests too.

markharwood commented 6 years ago

cc @elastic/es-search-aggs

imotov commented 4 years ago

@polyfractal should we assign these as well after we are done with the issue spring cleaning? :smile_cat:

imotov commented 3 years ago

I opened #71303, which hopefully will make writing these tests a bit less awkward.

nik9000 commented 3 years ago

One of the things I've been trying to do when I build these tests is assert that the we take fast paths when its important. Like, when we expect, say, range to get rewritten into a filter-by-filter style filters agg I'm writing a test with that uses the profiler results to assert that our debug output says we hit the fast path. Its not important to do in lots of cases, but, like, when I've spent several days writing fancy fast paths for stuff like range and terms I want to be sure we're not accidentally disabling them. And REST tests are the only place I can be sure of that.

chen-ni commented 2 years ago

Hi @polyfractal, I'd like to work on adding tests but I have a question. Why does every yml file start with an (seemingly) arbitrary number? Like 220_filters_bucket.yml, 230_composite.yml, etc. How do I come up with the number when adding a test file?

not-napoleon commented 2 years ago

The numbering is fairly arbitrary. Feel free to just pick the next available multiple of ten and start there. I believe there are historical reasons for it, but at this point it's mostly tradition. Thanks for helping out!

nik9000 commented 2 years ago

I believe there are historical reasons for it, but at this point it's mostly tradition.

Reminds me of writing basic in middle school.

not-napoleon commented 2 years ago

Reminds me of writing basic in middle school.

I can't tell if that's a point in favor of or against continuing the practice.

elasticsearchmachine commented 2 years ago

Pinging @elastic/es-analytics-geo (Team:Analytics)

elasticsearchmachine commented 3 months ago

Pinging @elastic/es-analytical-engine (Team:Analytics)

elastic / elasticsearch