For testing Elasticsearch, have you ever thought of doing two runs of the
junit4 plugin? One to grab the fast unit tests first and one to grab the
integration tests? I know most of the tests are integration tests but you
might be able to squeeze some speed out of the process by parallelizing the
unit tests. Maybe some of the integration tests can be parallelized too?
You can run the tests in parallel by specifying -Dtests.jvms=${number of
tests to run concurrently} The default has been 1 for a very long time but
Simon recently changed it so that it now picks a number that depends on
your number of CPUs. For instance I have 8 CPUs here and by default it
would start 4 JVMs.
Moreover, since the beginning of the week, some (enough so that the speedup
is noticeable) of our integration tests are faster since instead of
indexing documents on every test, they are only indexed at the beginning of
the test suite.
You might also be interested in running with -Dtests.slow=true which is
supposed to only run the fast tests. It can be helpful when iterating on a
feature to get a sense of whether a change broke something. (The default is
false.)
On Thu, Apr 10, 2014 at 3:06 PM, Nikolas Everett nik9000@gmail.com wrote:
For testing Elasticsearch, have you ever thought of doing two runs of the
junit4 plugin? One to grab the fast unit tests first and one to grab the
integration tests? I know most of the tests are integration tests but you
might be able to squeeze some speed out of the process by parallelizing the
unit tests. Maybe some of the integration tests can be parallelized too?
You can run the tests in parallel by specifying -Dtests.jvms=${number of
tests to run concurrently} The default has been 1 for a very long time but
Simon recently changed it so that it now picks a number that depends on
your number of CPUs. For instance I have 8 CPUs here and by default it
would start 4 JVMs.
Moreover, since the beginning of the week, some (enough so that the
speedup is noticeable) of our integration tests are faster since instead of
indexing documents on every test, they are only indexed at the beginning of
the test suite.
You might also be interested in running with -Dtests.slow=true which is
supposed to only run the fast tests. It can be helpful when iterating on a
feature to get a sense of whether a change broke something. (The default is
false.)
On Thu, Apr 10, 2014 at 3:06 PM, Nikolas Everett nik9000@gmail.comwrote:
For testing Elasticsearch, have you ever thought of doing two runs of the
junit4 plugin? One to grab the fast unit tests first and one to grab the
integration tests? I know most of the tests are integration tests but you
might be able to squeeze some speed out of the process by parallelizing the
unit tests. Maybe some of the integration tests can be parallelized too?
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.