Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <2097010572.1139492518053.JavaMail.jira@ajax.apache.org>
Date: Thu, 9 Feb 2006 14:41:58 +0100 (CET)
From: "Kristian Waagan (JIRA)" <derby-dev@db.apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-918) introduce a new test type to run
 junit tests from the current harness
In-Reply-To: <1697414522.1138968785874.JavaMail.jira@ajax.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

    [ http://issues.apache.org/jira/browse/DERBY-918?page=comments#action_12365729 ] 

Kristian Waagan commented on DERBY-918:
---------------------------------------

(Sorry for accidentally finding a keyboard shortcut that submitted the comment before I was finished...)
 I have one comment related to the patch, or actually a comment in the patch:

        else if (testType.equals("junit"))
        {
            System.out.println("JUnit tests not implemented yet with useprocess=false");
            System.exit(1);
            
            // This does not compile since JUnit is not in the CLASSPATH
            //junit.textui.TestRunner.run
            //(new junit.framework.TestSuite(Class.forName(javaPath + "." + testBase)));
        } 

If we use the way described in the comment to start the test, it will differ from how we do it when useprocess=true. When we start the testrunner from the command line, it will use the method 'BaseTestRunner.getTest', which uses reflection to call the test class' 'suite' method. The way described by the comment will also use reflection, but it will get a list of all methods in the test class and find those that starts with 'test'.

The latter case would cause any test setup done/initiated from 'suite' to be skipped. I have observed on the developer list that we have talked about using a test decorator, like 'TestSetup', to create a common test setup/environment for the tests in the suite (or test class). 'suite' could also possibly skip one or more test methods that is known to fail, but these would be included in the latter case.

I know this is a little ahead of time, but I would rather see the comment deleted, to make sure we don't simply uncomment it later and expect things to work as before.

> introduce a new test type to run junit tests from the current harness
> ---------------------------------------------------------------------
>
>          Key: DERBY-918
>          URL: http://issues.apache.org/jira/browse/DERBY-918
>      Project: Derby
>         Type: Improvement
>   Components: Test
>  Environment: All
>     Reporter: Andreas Korneliussen
>     Assignee: Andreas Korneliussen
>  Attachments: DERBY-918.diff, DERBY-918.stat
>
> It seems to me that for including a new JUnit test into i.e derby-all we need to make a new java class with a main() method, which parses a command line and set up the testsuite and run it, just like any java program. Basically we are running the junit tests as test type "java".
> Instead of having to do this for every junit test going into a derby test suite, I would propose a different strategy.
> I propose to introduce a new test type called "junit" (current test types are: sql,sql2,unit,java,multi,demo - unit is not junit)
> Then you can use:
> java org.apache.derbyTesting.functionTests.harness.RunTest <TestCaseClassName>.junit
> to run a Junit test - instead of:
> java org.apache.derbyTesting.functionTests.harness.RunTest <AnotherClassWithMainMethod>.java
> When starting a test of type junit, the RunTest class may simply use the
> junit.textui.TestRunner class, which has a main method which takes a TestCase class name as parameter.  The junit.textui.TestRunner  runs the tests defined by the suite() method of the TestCase class.
> I think this strategy will make it easier to integrate new JUnit tests into the current test suites, since it save you the trouble of creating a java class with a main method for every test.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira