drill-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DRILL-2026) Consider: speed up dev. tests using Maven "integration-test" phase
Date Wed, 26 Aug 2015 22:31:45 GMT

    [ https://issues.apache.org/jira/browse/DRILL-2026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14715643#comment-14715643
] 

Andrew commented on DRILL-2026:
-------------------------------

I started taking a look at this and have provided my initial ideas in the PR referenced below.

My approach is three-fold.

First, make the distinction between integration and unit tests clearer. This should be reflected
in the type hierarchy and naming conventions for the tests. I propose to have, at a top-level,
an abstract class DrillTestBase. This class sets up utilities common to all tests, including
utilities for randomizing test inputs. Extending DrillTestBase are two additional abstract
classes: DrillIntegrationTestBase and DrillUnitTestBase. 

DrillIntegrationTestBase basically does everything that BaseTestQuery does today. In other
words, it starts and stops the drillbits, MemWatcher, SystemManager, and log reporter. DrillUnitTestBase
is currently empty; existing only at this time for enforcing an explicit type hierarchy.

Second, we should provide facilities for adding randomization to our tests. I have designed
DrillTestBase to use the randomized testing utilities from the Carrot project (http://labs.carrotsearch.com/randomizedtesting.html).
Using randomization in tests is optional, but is to be encouraged as it adds an extremely
useful layer of robustness to testing. Take a look at the Elasticsearch and Lucene projects
as examples of how this can be done well.

Finally, we should move to the Maven failsafe plugin (as mentioned above) for running integration
tests. Running 'mvn test' should only invoke the unit tests. This will make the build much
more developer friendly and save a huge amount of time during development iteration. I have
left this part out of the current PR because I'd like to get feedback on the above two points
first.

This PR has my initial thoughts around how this should look: https://github.com/apache/drill/pull/135

> Consider: speed up dev. tests using Maven "integration-test" phase
> ------------------------------------------------------------------
>
>                 Key: DRILL-2026
>                 URL: https://issues.apache.org/jira/browse/DRILL-2026
>             Project: Apache Drill
>          Issue Type: Improvement
>          Components: Tools, Build & Test
>            Reporter: Daniel Barclay (Drill)
>            Assignee: Jason Altekruse
>             Fix For: 1.2.0
>
>
> Because many of our unit test classes (unit tests in the sense of being run by Surefire
in Maven's "test" phase) need to have a running Drillbit, then because they are unit tests,
each such test class starts up its own Drillbit, taking quite a while, especially considering
the aggregate time.
> Consider moving Drillbit-needing tests to be Maven integration tests (run in Maven's
"integration-test" phase by Failsafe).
> That would allow for starting up a Drillbit (or multiple Drillbits and other servers)
in Maven's "pre-integration-test" phase, using those servers for all tests, and shutting down
the servers in Maven's "post-integration-test" phase.
> That should save quite a lot of time--the product of the time per Drillbit startup plus
shutdown and the number of test classes changed to integration tests.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message