integration testsedit

These kind of tests require firing up a whole cluster of nodes, before the tests can actually be run. Compared to unit tests they are obviously way more time consuming, but the test infrastructure tries to minimize the time cost by only restarting the whole cluster, if this is configured explicitly.

The class your tests have to inherit from is ElasticsearchIntegrationTest. As soon as you inherit, there is no need for you to start any elasticsearch nodes manually in your test anymore, though you might need to ensure that at least a certain number of nodes is up.

number of shardsedit

The number of shards used for indices created during integration tests is randomized between 1 and 10 unless overwritten upon index creation via index settings. Rule of thumb is not to specify the number of shards unless needed, so that each test will use a different one all the time.

generic helper methodsedit

There are a couple of helper methods in ElasticsearchIntegrationTest, which will make your tests shorter and more concise.


Refreshes all indices in a cluster


Ensures a green health cluster state, waiting for relocations. Waits the default timeout of 30 seconds before failing.


Ensures a yellow health cluster state, also waits for 30 seconds before failing.


Creates an index with the specified name


Flushes all indices in a cluster


Combines flush() and refresh() calls


Waits for all relocations and optimized all indices in the cluster to one segment.


Checks if given index exists


Returns an AdminClient for administrative tasks


Returns the cluster service java class


Returns the test cluster class, which is explained in the next paragraphs

test cluster methodsedit

The TestCluster 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.


Ensure at least the specified number of nodes is running in the cluster


Ensure at most the specified number of nodes is running in the cluster


Get a guice instantiated instance of a class from a random node


Get a guice instantiated instance of a class from a specified node


Stop a random node in your cluster to mimic an outage


Stop the current master node to force a new election


Stop a random non master node to mimic an outage


Create a new elasticsearch node


Create and start a new elasticsearch node

Accessing clientsedit

In order to execute any actions, you have to use a client. You can use the ElasticsearchIntegrationTest.client() method to get back a random client. This client can be a TransportClient or a NodeClient - and usually you do not need to care as long as the action gets executed. There are several more methods for client selection inside of the TestCluster class, which can be accessed using the ElasticsearchIntegrationTest.cluster() method.


An iterator over all available clients


Returns a client which is connected to the master node


Returns a client which is not connected to the master node


Returns a client, which is running on a client node

client(String nodeName)

Returns a client to a given node


Returns a smart client


By default the tests are run without restarting the cluster between tests or test classes in order to be as fast as possible. Of course all indices and templates are deleted between each test. However, sometimes you need to start a new cluster for each test or for a whole test suite - for example, if you load a certain plugin, but you do not want to load it for every test.

You can use the @ClusterScope annotation at class level to configure this behaviour

@ClusterScope(scope=SUITE, numNodes=1)
public class CustomSuggesterSearchTests extends ElasticsearchIntegrationTest {
  // ... tests go here

The above sample configures an own cluster for this test suite, which is the class. Other values could be GLOBAL (the default) or TEST in order to spawn a new cluster for each test. The numNodes settings allows you to only start a certain number of nodes, which can speed up test execution, as starting a new node is a costly and time consuming operation and might not be needed for this test.

Changing node configurationedit

As elasticsearch is using JUnit 4, using the @Before and @After annotations is not a problem. However you should keep in mind, that this does not have any effect in your cluster setup, as the cluster is already up and running when those methods are run. So in case you want to configure settings - like loading a plugin on node startup - before the node is actually running, you should overwrite the nodeSettings() method from the ElasticsearchIntegrationTest class and change the cluster scope to SUITE.

protected Settings nodeSettings(int nodeOrdinal) {
  return ImmutableSettings.settingsBuilder()
           .put("plugin.types", CustomSuggesterPlugin.class.getName())