Daniel Barclay (Drill/MapR) created DRILL-1744:
--------------------------------------------------

             Summary: Many unit tests fail when run outside Maven (e.g., in 
Eclipse)
                 Key: DRILL-1744
                 URL: https://issues.apache.org/jira/browse/DRILL-1744
             Project: Apache Drill
          Issue Type: Bug
            Reporter: Daniel Barclay (Drill/MapR)


Many of the JUnit unit tests fail when run in Eclipse even though they seem to 
work when run using Maven.  

It seems that some of the setup required to run the tests is missing from the 
test classes and is only in the Maven configuration.

(To confirm that it's not Eclipse-specific, I tried checking using the plain 
JUnit test runner from the command line, but don't know what all to put in the 
classpath (e.g., to eliminate errors such as "java.lang.SecurityException: 
Invalid signature file digest for Manifest main attributes").)


In invoking "Run As" . "JUnit Test" on drill-java-exec, 48 of 375 test methods 
fail with errors.  (None fail assertions.)  The status of the remaining 215 
isn't clear; an out-of-memory failure hangs the JUnit run.

In drill-jdbc, 125 of the 153 tests yield errors.

In drill-storage-hbase, most tests yield errors.

In drill-common, in CheckStorageConfig, one test fails with an error and the 
other fails an assertion.


The drill-jdbc failures seem to be because the tests don't disable the Jetty 
server.  (Running some test method individually works, and running multiple 
tests yields BindExceptions for all but the first.)

Strangely, running org.apache.drill.exec.physical.impl.TopN.TestSimpleTopN by 
itself also yields a BindException.


The tests should probably be written so that they run in environments other 
than a Maven run (e.g., in common JUnit runners) as much as possible. 

Any settings that can't be configured in the tests (e.g., JVM memory settings?) 
should be documented somewhere (maybe in the Developing Drill pages of the 
wiki, maybe somewhere in the code).  (Possibly some code should check 
Runtime.getRuntime().maxMemory() and warn when appropriate.)





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

Reply via email to