Hi Tim,

Here’s another thought. JUnit & SureFire have a way of grouping tests into 
categories. The classic grouping are the “fast” tests we want to run all the 
time, and the “slow” tests we run occasionally. I recently tried to get this 
working to move a couple of tests into the slow category.

Perhaps we can also group tests by domain. For example, if someone is mucking 
with the web UI, they don’t really need to run all the storage plugin tests. If 
someone works with the planner, they don’t really need to stress test value 
vectors.

Github builds might run a “smoke test” subset. The build process prior to a 
release might run all the tests.

IMHO, we want to encourage more tests, without people thinking, “gee, I don’t 
want to make the build slower, so I’ll go light on my new tests…”

Thanks,

- Paul

> On Aug 29, 2017, at 2:08 PM, Timothy Farkas <tfar...@mapr.com> wrote:
> 
> Thanks Paul,
> 
> I see now the parent pom already configures surefire to fork 2 processes to 
> run tests. I tried running multiple tests in parallel in each forked process, 
> but there were errors with BaseTestQuery, probably because it uses static 
> variables. One additional speedup I found was that the maven -T flag 
> parallelizes the build and also seems to parallelize running the tests across 
> sub modules. Using that flag the test duration for contrib went from 18 
> minutes to 10 minutes.
> 
> I'll investigate making BaseTestQuery thread safe. Maybe we can get more 
> speedups from being able to run multiple tests in parallel in the same 
> process as well.
> 
> Tim
> 
> ________________________________
> From: Paul Rogers <prog...@mapr.com>
> Sent: Monday, August 28, 2017 6:39:10 PM
> To: dev@drill.apache.org
> Subject: Re: Speeding Up Unit Tests
> 
> Tests run in parallel when run from the command line in Maven. We have had 
> issues, especially when some test changes global state. Can’t remember the 
> details, however.
> 
> - Paul
> 
>> On Aug 28, 2017, at 6:04 PM, Timothy Farkas <tfar...@mapr.com> wrote:
>> 
>> Hi All,
>> 
>> I will be working on 
>> DRILL-5730<https://issues.apache.org/jira/browse/DRILL-5730>  and see some 
>> other areas for potential improvement with regard to testing:
>> 
>> 1.  Add caching of maven artifacts to the Travis build. This should 
>> significantly speed up compiling the code in travis.
>> 2.  Running unit tests in parallel.
>> 3.  Make the Travis build actually run unit tests (currently it does not).
>> 
>> Points (1) and (3) are easy to do, but I was wondering if anyone has 
>> experience with some of the potential pitfalls of running unit tests in 
>> parallel? Are there certain tests which will have race conditions? and are 
>> there any foreseeable issues with running multiple embedded drill bits in 
>> parallel?
>> 
>> Thanks,
>> Tim
>> 
>> 
> 

Reply via email to