# Approaches for ensuring clean state for automated testing **URL:** \ **Category:** Elasticsearch\ **Created:** [August 6, 2013, 9:46pm UTC](https://discuss.elastic.co/t/approaches-for-ensuring-clean-state-for-automated-testing/13097 "2013-08-06T21:46:43Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![Edward\_Sargisson](https://avatars.discourse-cdn.com/v4/letter/e/b4bc9f/32.png) [@Edward\_Sargisson](https://discuss.elastic.co/u/Edward_Sargisson)\ **Post date:** [August 6, 2013, 9:46pm UTC](https://discuss.elastic.co/t/approaches-for-ensuring-clean-state-for-automated-testing/13097/1 "2013-08-06T21:46:43Z")
Hi all, What approaches do you use to ensure your elasticsearch indices are at a known state when writing automated tests? Background: We have a high-spec machine which is shared by a number of environments for development and testing. We have continuous integration tests which run against that machine. Thus far, the approach has been to delete known indices and allow the test to automatically recreate them. In recent days, a large amount of data has been added to other, unrelated indices.It appears that what is now happening is that deleting the index causes the node to run the shard re-allocation process. In the meantime the test creates a document (which should automatically create the index) but this fails because it is delayed for too long by the shard re-allocation. Possible approaches: Therefore we are considering approaches where we do not delete the index all the time. We either: a) ensure every document in the index is deleted before running each test b) record every document we add and delete them after the test. So what do other people do? Cheers, Edward -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![nik9000](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/nik9000/32/44947_2.png) [@nik9000](https://discuss.elastic.co/u/nik9000)\ **Post date:** [August 6, 2013, 9:59pm UTC](https://discuss.elastic.co/t/approaches-for-ensuring-clean-state-for-automated-testing/13097/2 "2013-08-06T21:59:19Z")
Could you turn off shard reallocation or throttle it down somehow? Of the two options you have enumerated I'd go with (a) because that makes the test more resilient to crashes and leaves the indecies in a post-test run state which can be useful for playing around. If you aren't using much data you may want to spin up elasticsearch as part of your automated test suite and connect to it. Nik On Tue, Aug 6, 2013 at 5:46 PM, Edward Sargisson [ejsarge@gmail.com](mailto:ejsarge@gmail.com) wrote: > Hi all, > What approaches do you use to ensure your elasticsearch indices are at a > known state when writing automated tests? > > Background: > We have a high-spec machine which is shared by a number of environments > for development and testing. We have continuous integration tests which run > against that machine. Thus far, the approach has been to delete known > indices and allow the test to automatically recreate them. > > In recent days, a large amount of data has been added to other, unrelated > indices.It appears that what is now happening is that deleting the index > causes the node to run the shard re-allocation process. In the meantime the > test creates a document (which should automatically create the index) but > this fails because it is delayed for too long by the shard re-allocation. > > Possible approaches: > Therefore we are considering approaches where we do not delete the index > all the time. We either: > a) ensure every document in the index is deleted before running each test > b) record every document we add and delete them after the test. > > So what do other people do? > > Cheers, > Edward > > -- > You received this message because you are subscribed to the Google Groups > "elasticsearch" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). > For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 6, 2017, 2:22am UTC](https://discuss.elastic.co/t/approaches-for-ensuring-clean-state-for-automated-testing/13097/3 "2017-07-06T02:22:35Z")