anchor.diff:  [[testing-framework]]
  -== Java Testing Framework
  +== Java 测试框架
   
   [[testing-intro]]
   
  -Testing is a crucial part of your application, and as information retrieval itself is already a complex topic, there should not be any additional complexity in setting up a testing infrastructure, which uses elasticsearch. This is the main reason why we decided to release an additional file to the release, which allows you to use the same testing infrastructure we do in the elasticsearch core. The testing framework allows you to setup clusters with multiple nodes in order to check if your code covers everything needed to run in a cluster. The framework prevents you from writing complex code yourself to start, stop or manage several test nodes in a cluster. In addition there is another very important feature called randomized testing, which you are getting for free as it is part of the elasticsearch infrastructure.
  -
  +测试是应用程序中关键的一环， 特别是对elasticsearch属于信息检索这样的一个本身就很复杂的领域，
  +就更不应该在搭建测试基础设施上增加复杂性了。这就是我们在发布版本中添加一个额外的文件，让你可以使用和elasticsearch核心模块同意的测试框架的一个主要原因。 这个测试框架让你可以搭建一个多节点的集群，从而可以检查代码是否覆盖了集群环境运行情况下得各种情况。这个框架不需要你写很复杂的代码来启动，停止或者管理集群中的一些测试节点。更进一步，发布版本中还包含一个重要功能，叫做随机测试，因为这是elasticsearch基础设施的一部分，因此你可以免费使用。
   
   
   [[why-randomized-testing]]
  -=== why randomized testing?
  -
  -The key concept of randomized testing is not to use the same input values for every testcase, but still be able to reproduce it in case of a failure. This allows to test with vastly different input variables in order to make sure, that your implementation is actually independent from your provided test data.
  -
  -All of the tests are run using a custom junit runner, the `RandomizedRunner` provided by the randomized-testing project. If you are interested in the implementation being used, check out the http://labs.carrotsearch.com/randomizedtesting.html[RandomizedTesting webpage].
  -
  +=== 为什么需要随机测试？
  +
  +随机测试的核心概念是不在每个测试用例中使用相同的输入值，但在错误发生时依然可以重现问题。这样举可以使用各种不同的输入变量来进行测试，从而确保你的实现与你提供的测试数据是独立的。
  +所有测试都使用一个自定义junit runner， 叫做 `RandomizedRunner`， 该runner由随机测试项目提供。 如果你对实现细节感兴趣， 请参考 http://labs.carrotsearch.com/randomizedtesting.html[随机测试网页].
   
   [[using-elasticsearch-test-classes]]
  -=== Using the elasticsearch test classes
  -
  -First, you need to include the testing dependency in your project, along with the elasticsearch dependency you have already added. If you use maven and its `pom.xml` file, it looks like this
  -
  +=== 使用 elasticsearch 测试类
  +
  +首先，你需要在添加elasticsearch依赖包的同时添加测试框架的依赖包到项目中。 如果你使用maven来管理项目，那么 pom.xml 文件看上去就像下面这样
   [[source,xml]]
  +
   --------------------------------------------------
   <dependencies>
     <dependency>
  
positive.code: </dependencies>
  --------------------------------------------------
  
  Replace the elasticsearch version and the lucene version with the corresponding elasticsearch version and its accompanying lucene release.
  
  We provide a few classes that you can inherit from in your own test classes which provide:
  
  * pre-defined loggers
  * randomized testing infrastructure
  * a number of helper methods
  
  
  [[unit-tests]]
  === unit tests
  
  If your test is a well isolated unit test which doesn't need a running elasticsearch cluster, you can use the `ESTestCase`. If you are testing lucene features, use `ESTestCase` and if you are testing concrete token streams, use the `ESTokenStreamTestCase` class. Those specific classes execute additional checks which ensure that no resources leaks are happening, after the test has run.
  
  
  [[integration-tests]]
  === integration tests
  
  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 `ESIntegTestCase`. By inheriting from this class, you will no longer need to start elasticsearch nodes manually in your test, although you might need to ensure that at least a certain number of nodes are up. The integration test behaviour can be configured heavily by specifying different system properties on test runs. See the `TESTING.asciidoc` documentation in the https://github.com/elastic/elasticsearch/blob/master/TESTING.asciidoc[source repository] for more information.
  
  
  [[number-of-shards]]
  ==== number of shards
  
  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.
  The 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. Alternatively you can override the `numberOfShards()` method. The same applies to the `numberOfReplicas()` method.
  
  
  [[helper-methods]]
  ==== generic helper methods
  
  There are a couple of helper methods in `ESIntegTestCase`, which will make your tests shorter and more concise.
  
  [horizontal]
  `refresh()`::           Refreshes all indices in a cluster
  `ensureGreen()`::       Ensures a green health cluster state, waiting for relocations. Waits the default timeout of 30 seconds before failing.
  `ensureYellow()`::      Ensures a yellow health cluster state, also waits for 30 seconds before failing.
  `createIndex(name)`::   Creates an index with the specified name
  `flush()`::             Flushes all indices in a cluster
  `flushAndRefresh()`::   Combines `flush()` and `refresh()` calls
  `optimize()`::          Waits for all relocations and optimized all indices in the cluster to one segment.
  `indexExists(name)`::   Checks if given index exists
  `admin()`::             Returns an `AdminClient` for administrative tasks
  `clusterService()`::    Returns the cluster service java class
  `cluster()`::           Returns the test cluster class, which is explained in the next paragraphs
  
  
  [[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
  `ensureAtMostNumNodes(n)`::         Ensure at most the specified number of nodes is running in the cluster
  `getInstance()`::                   Get a guice instantiated instance of a class from a random node
  `getInstanceFromNode()`::           Get a guice instantiated instance of a class from a specified node
  `stopRandomNode()`::                Stop a random node in your cluster to mimic an outage
  `stopCurrentMasterNode()`::         Stop the current master node to force a new election
  `stopRandomNonMaster()`::           Stop a random non master node to mimic an outage
  `buildNode()`::                     Create a new elasticsearch node
  `startNode(settings)`::             Create and start a new elasticsearch node
  
  
  [[changing-node-settings]]
  ==== Changing node settings
  
  If you want to ensure a certain configuration for the nodes, which are started as part of the `EsIntegTestCase`, you can override the `nodeSettings()` method
  
  [source,java]
  -----------------------------------------
  public class Mytests extends ESIntegTestCase {
  
negative.code: assertFirstHit(searchResponse, hasId("4"));
  assertSearchHits(searchResponse, "1", "2", "3", "4");
  ----------------------------
  