anchor.diff:  `hasId()`::     Matcher to check for a search hit id
   `hasType()`::   Matcher to check for a search hit type
   `hasIndex()`::  Matcher to check for a search hit index
  +`hasScore()`::  Matcher to check for a certain score of a hit
  +`hasStatus()`:: Matcher to check for a certain `RestStatus` of a response
   
   Usually, you would combine assertions and matchers in your test like this
   
  
positive.code:   return pluginList(CustomSuggesterPlugin.class);
  }
  -----------------------------------------
  
  [[parametrized-tests]]
  === parameterized tests
  
  It is possible to write parameterized tests, that get run multiple times with different parameters. `RandomizedRunner` needs to be used rather than the `Parameterized` runner provided with junit (all the base test classes already use `RandomizedRunner` though). The method that provides the parameters
  needs to be annotated with the `@ParametersFactory` annotation and must be `static`, `public`, without arguments and must have a return type assignable to `Iterable<Object[]>`. The iterable must return arrays conforming to the suite class's constructor with respect to the number and types of parameters.
  The constructor's parameters can be annotated with the `@Name` annotation to provide more descriptive parameter names for test descriptions. Have a look at `ElasticsearchRestTests` for an example.
  
  [[randomized-testing]]
  === Randomized testing
  
negative.code: [[test-cluster-methods]]
  ==== test cluster methods
  
  The `InternalTestCluster` class is the heart of the cluster functionality in a randomized test and allows you to configure a specific setting or replay certain types of outages to check, how your custom code reacts.
  
  [horizontal]
  `ensureAtLeastNumNodes(n)`::        Ensure at least the specified number of nodes is running in the cluster
  