Commit Graph

11 Commits

Author SHA1 Message Date
David Pursehouse b49e66c3a1 Replace references to ImmutableSettings with Settings
ImmutableSettings was merged into Settings in commit 4873070.

Change-Id: I06bd0150381d131593920c2328c46beacf49661f
2015-06-24 14:54:53 +09:00
Chelsea Lura 3ac19e8f7f Doc: Typo 'good' vs 'well' typo
Closes #11549
2015-06-09 09:25:23 +02:00
javanna ddcecc2bc2 [DOCS] added instructions on how to write parameterized tests
Closes #9423
2015-03-19 12:43:51 +01:00
Robert Muir 1e015e6e33 Tests: Remove global shared cluster
This was previously attempted in #8854. I revived that branch and did
some performance testing as was suggested in the comments there.

I fixed all the errors, mostly just the rest tests, which
needed to have http enabled on the node settings (the global cluster
previously had this always enabled). I also addressed the comments from
that issue.

My performance tests involved running the entire test suite on my
desktop which has 6 cores, 16GB of ram, and nothing else was being
run on the box at the time. I ran each set of settings 3 times and
took the average time.

| mode    | master | patch | diff |
| ------- | ------ | ----- | ---- |
| local   | 409s   | 417s  | +2%  |
| network | 368s   | 380s  | +3%  |

This increase in average time is clearly worthwhile to pay to achieve
isolation of tests. One caveat is the way I fixed the rest tests
is still to have one cluster for the entire suite, so all the rest
tests can still potentially affect each other, but this is an
issue for another day.

There were some oddities that I noticed while running these tests
that I would like to point out, as they probably deserve some
investigation (but orthogonal to this PR):
* The total test run times are highly variable (more than a minute between the min and max)
* Running in network mode is on average actually *faster* than local mode. How is this possible!?
2015-02-22 22:04:22 -08:00
Jun Ohtani d78d2ff93d Docs: add randomizedtesting-runner to testing-framework.asciidoc
Close #8450
2014-12-07 01:30:58 +09:00
Dan Tuffery 3b5fa9075a Docs: Grammar correction
Closes #8702
2014-11-29 14:06:04 +01:00
Veres Lajos 4059e4ac86 typo fixes - https://github.com/vlajos/misspell_fixer
Closes #8323
2014-11-08 18:55:57 +01:00
Clinton Gormley cb00d4a542 Docs: Removed all the added/deprecated tags from 1.x 2014-09-26 21:04:42 +02:00
javanna d5aaa90f34 [TEST] Randomized number of shards used for indices created during tests
Introduced two levels of randomization for the number of shards (between 1 and 10) when running tests:

1) through the existing random index template, which now sets a random number of shards that is shared across all the indices created in the same test method unless overwritten

2) through `createIndex` and `prepareCreate` methods, similar to what happens using the `indexSettings` method, which changes for every `createIndex` or `prepareCreate` unless overwritten (overwrites index template for what concerns the number of shards)

Added the following facilities to deal with the random number of shards:
- `getNumShards` to retrieve the number of shards of a given existing index, useful when doing comparisons based on the number of shards and we can avoid specifying a static number. The method returns an object containing the number of primaries, number of replicas and the total number of shards for the existing index

- added `assertFailures` that checks that a shard failure happened during a search request, either partial failure or total (all shards failed). Checks also the error code and the error message related to the failure. This is needed as without knowing the number of shards upfront, when simulating errors we can run into either partial (search returns partial results and failures) or total failures (search returns an error)

- added common methods similar to `indexSettings`, to be used in combination with `createIndex` and `prepareCreate` method and explicitly control the second level of randomization: `numberOfShards`, `minimumNumberOfShards` and `maximumNumberOfShards`. Added also `numberOfReplicas` despite the number of replicas is not randomized (default not specified but can be overwritten by tests)

Tests that specified the number of shards have been reviewed and the results follow:
- removed number_of_shards in node settings, ignored anyway as it would be overwritten by both mechanisms above
- remove specific number of shards when not needed
- removed manual shards randomization where present, replaced with ordinary one that's now available
- adapted tests that didn't need a specific number of shards to the new random behaviour
- fixed a couple of test bugs (e.g. 3 levels parent child test could only work on a single shard as the routing key used for grand-children wasn't correct)
- also done some cleanup, shared code through shard size facets and aggs tests and used common methods like `assertAcked`, `ensureGreen`, `refresh`, `flush` and `refreshAndFlush` where possible
- made sure that `indexSettings()` is always used as a basis when using `prepareCreate` to inject specific settings
- converted indexRandom(false, ...) + refresh to indexRandom(true, ...)
2014-03-10 13:01:52 +01:00
Simon Willnauer e6ace1313e [DOCS]: fixed added / coming tags in docs 2014-01-22 12:02:37 +01:00
Alexander Reelsen 6528df2764 [DOCS] Test framework documentation
The java test framework using randomized testing is explained with a couple of examples.
2013-12-02 18:01:45 +01:00