I have a test suite, which assumes a certain fixture dataset is loaded into
MySQL and ElasticSearch prior to running. Loading this data is only done
when the fixture data changes, which is quite infrequent. When running the
tests, changes to MySQL are rolled back using transactions. Changes to ES,
I currently don't have a good way to handle, as I can't simply clear out
the test index after every test case. Instead the tests need to take this
into account.
Is there a clever way to discard changes made to ES during a test case? I
have this (possibly terrible) idea of disabling translog flushing and then
somehow making ES drop the translog afterwards, but I have no idea whether
that's feasible at all.
since loading something into elasticsearch is really fast, we load our test
from the DB into ES just before we start our test suite (in the @BeforeClass of the parent class of our ES tests). We do this only if the
indices are not present in ES.
We have a special jUnit test suite so we could do this also in the suite
and tear down after all tests run.
Of course we try to minimize the data which is needed for our tests. So, to
initialization before our 3000 test takes about 20s (but this is because
the DB is the bottle neck).
Best regards,
Daniel
Am Mittwoch, 21. August 2013 08:06:39 UTC+2 schrieb Andreas Garnæs:
I have a test suite, which assumes a certain fixture dataset is loaded
into MySQL and Elasticsearch prior to running. Loading this data is only
done when the fixture data changes, which is quite infrequent. When running
the tests, changes to MySQL are rolled back using transactions. Changes to
ES, I currently don't have a good way to handle, as I can't simply clear
out the test index after every test case. Instead the tests need to take
this into account.
Is there a clever way to discard changes made to ES during a test case? I
have this (possibly terrible) idea of disabling translog flushing and then
somehow making ES drop the translog afterwards, but I have no idea whether
that's feasible at all.
How do you make sure your test cases are independent? If two test cases
both modify ES they could step on each others toes unless the changes are
"rolled back".
Thanks,
Andreas
On Wednesday, 21 August 2013 08:29:36 UTC+2, daniel koller wrote:
Hi Andreas,
since loading something into elasticsearch is really fast, we load our
test from the DB into ES just before we start our test suite (in the @BeforeClass of the parent class of our ES tests). We do this only if the
indices are not present in ES.
We have a special jUnit test suite so we could do this also in the suite
and tear down after all tests run.
Of course we try to minimize the data which is needed for our tests. So,
to initialization before our 3000 test takes about 20s (but this is because
the DB is the bottle neck).
Best regards,
Daniel
Am Mittwoch, 21. August 2013 08:06:39 UTC+2 schrieb Andreas Garnæs:
I have a test suite, which assumes a certain fixture dataset is loaded
into MySQL and Elasticsearch prior to running. Loading this data is only
done when the fixture data changes, which is quite infrequent. When running
the tests, changes to MySQL are rolled back using transactions. Changes to
ES, I currently don't have a good way to handle, as I can't simply clear
out the test index after every test case. Instead the tests need to take
this into account.
Is there a clever way to discard changes made to ES during a test case? I
have this (possibly terrible) idea of disabling translog flushing and then
somehow making ES drop the translog afterwards, but I have no idea whether
that's feasible at all.
A) we have some tests which use the global test-fixture (data loaded at the
start of the suite)
B) we have some tests which use the same test-fixture for all test methods
of a class (data loaded in the @BeforeClass method and reset in the @AfterClass method), they use other index names then used in the global
fixture
C) we have some tests which need a fresh fixture for every method (data
loaded in the @Before and reset in the @After method), again other indicies
names then A) and B)
All tests of a category A, B, or C share a parent class which delivers a
prefix for the index name for there subclasses, so we never get a conflict
between them.
Best regards,
Daniel
Am Mittwoch, 21. August 2013 08:35:38 UTC+2 schrieb Andreas Garnæs:
Hi Daniel,
Thanks for your reply.
How do you make sure your test cases are independent? If two test cases
both modify ES they could step on each others toes unless the changes are
"rolled back".
Thanks,
Andreas
On Wednesday, 21 August 2013 08:29:36 UTC+2, daniel koller wrote:
Hi Andreas,
since loading something into elasticsearch is really fast, we load our
test from the DB into ES just before we start our test suite (in the @BeforeClass of the parent class of our ES tests). We do this only if the
indices are not present in ES.
We have a special jUnit test suite so we could do this also in the suite
and tear down after all tests run.
Of course we try to minimize the data which is needed for our tests. So,
to initialization before our 3000 test takes about 20s (but this is because
the DB is the bottle neck).
Best regards,
Daniel
Am Mittwoch, 21. August 2013 08:06:39 UTC+2 schrieb Andreas Garnæs:
I have a test suite, which assumes a certain fixture dataset is loaded
into MySQL and Elasticsearch prior to running. Loading this data is only
done when the fixture data changes, which is quite infrequent. When running
the tests, changes to MySQL are rolled back using transactions. Changes to
ES, I currently don't have a good way to handle, as I can't simply clear
out the test index after every test case. Instead the tests need to take
this into account.
Is there a clever way to discard changes made to ES during a test case?
I have this (possibly terrible) idea of disabling translog flushing and
then somehow making ES drop the translog afterwards, but I have no idea
whether that's feasible at all.
In the JDBC river, I have an extensive set of in-memory RDBMS test cases.
The cases are organized by testng annotations. To discard changes, I simply
shutdown ES after each test. If you set the gateway to none, the index is
gone.
If you want to test a chain of situations, depending on data already
indexed, I would suggest using a test suite.
I have a test suite, which assumes a certain fixture dataset is loaded
into MySQL and Elasticsearch prior to running. Loading this data is only
done when the fixture data changes, which is quite infrequent. When running
the tests, changes to MySQL are rolled back using transactions. Changes to
ES, I currently don't have a good way to handle, as I can't simply clear
out the test index after every test case. Instead the tests need to take
this into account.
Is there a clever way to discard changes made to ES during a test case? I
have this (possibly terrible) idea of disabling translog flushing and then
somehow making ES drop the translog afterwards, but I have no idea whether
that's feasible at all.
Thanks for elaborating. Does B) and C) mean that you "manually undo" the
changes made in the test case(s) in @AfterClass/@After?
On Wednesday, 21 August 2013 08:49:27 UTC+2, daniel koller wrote:
Hi Andreas,
A) we have some tests which use the global test-fixture (data loaded at
the start of the suite)
B) we have some tests which use the same test-fixture for all test methods
of a class (data loaded in the @BeforeClass method and reset in the @AfterClass method), they use other index names then used in the global
fixture
C) we have some tests which need a fresh fixture for every method (data
loaded in the @Before and reset in the @After method), again other indicies
names then A) and B)
All tests of a category A, B, or C share a parent class which delivers a
prefix for the index name for there subclasses, so we never get a conflict
between them.
Best regards,
Daniel
Am Mittwoch, 21. August 2013 08:35:38 UTC+2 schrieb Andreas Garnæs:
Hi Daniel,
Thanks for your reply.
How do you make sure your test cases are independent? If two test cases
both modify ES they could step on each others toes unless the changes are
"rolled back".
Thanks,
Andreas
On Wednesday, 21 August 2013 08:29:36 UTC+2, daniel koller wrote:
Hi Andreas,
since loading something into elasticsearch is really fast, we load our
test from the DB into ES just before we start our test suite (in the @BeforeClass of the parent class of our ES tests). We do this only if the
indices are not present in ES.
We have a special jUnit test suite so we could do this also in the suite
and tear down after all tests run.
Of course we try to minimize the data which is needed for our tests. So,
to initialization before our 3000 test takes about 20s (but this is because
the DB is the bottle neck).
Best regards,
Daniel
Am Mittwoch, 21. August 2013 08:06:39 UTC+2 schrieb Andreas Garnæs:
I have a test suite, which assumes a certain fixture dataset is loaded
into MySQL and Elasticsearch prior to running. Loading this data is only
done when the fixture data changes, which is quite infrequent. When running
the tests, changes to MySQL are rolled back using transactions. Changes to
ES, I currently don't have a good way to handle, as I can't simply clear
out the test index after every test case. Instead the tests need to take
this into account.
Is there a clever way to discard changes made to ES during a test case?
I have this (possibly terrible) idea of disabling translog flushing and
then somehow making ES drop the translog afterwards, but I have no idea
whether that's feasible at all.
yes, since the super classes provide the @Before(Class) and @After(Class),
they know which indices they have created and can delete them.
Depending on the number of test and the execution speed you need you might
choose a A, B or C fixture for your tests.
Best regards,
Daniel
Am Mittwoch, 21. August 2013 12:03:39 UTC+2 schrieb Andreas Garnæs:
Thanks for elaborating. Does B) and C) mean that you "manually undo" the
changes made in the test case(s) in @AfterClass/@After?
On Wednesday, 21 August 2013 08:49:27 UTC+2, daniel koller wrote:
Hi Andreas,
A) we have some tests which use the global test-fixture (data loaded at
the start of the suite)
B) we have some tests which use the same test-fixture for all test
methods of a class (data loaded in the @BeforeClass method and reset in the @AfterClass method), they use other index names then used in the global
fixture
C) we have some tests which need a fresh fixture for every method (data
loaded in the @Before and reset in the @After method), again other indicies
names then A) and B)
All tests of a category A, B, or C share a parent class which delivers a
prefix for the index name for there subclasses, so we never get a conflict
between them.
Best regards,
Daniel
Am Mittwoch, 21. August 2013 08:35:38 UTC+2 schrieb Andreas Garnæs:
Hi Daniel,
Thanks for your reply.
How do you make sure your test cases are independent? If two test cases
both modify ES they could step on each others toes unless the changes are
"rolled back".
Thanks,
Andreas
On Wednesday, 21 August 2013 08:29:36 UTC+2, daniel koller wrote:
Hi Andreas,
since loading something into elasticsearch is really fast, we load our
test from the DB into ES just before we start our test suite (in the @BeforeClass of the parent class of our ES tests). We do this only if the
indices are not present in ES.
We have a special jUnit test suite so we could do this also in the
suite and tear down after all tests run.
Of course we try to minimize the data which is needed for our tests.
So, to initialization before our 3000 test takes about 20s (but this is
because the DB is the bottle neck).
Best regards,
Daniel
Am Mittwoch, 21. August 2013 08:06:39 UTC+2 schrieb Andreas Garnæs:
I have a test suite, which assumes a certain fixture dataset is loaded
into MySQL and Elasticsearch prior to running. Loading this data is only
done when the fixture data changes, which is quite infrequent. When running
the tests, changes to MySQL are rolled back using transactions. Changes to
ES, I currently don't have a good way to handle, as I can't simply clear
out the test index after every test case. Instead the tests need to take
this into account.
Is there a clever way to discard changes made to ES during a test
case? I have this (possibly terrible) idea of disabling translog flushing
and then somehow making ES drop the translog afterwards, but I have no idea
whether that's feasible at all.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.