You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Daniel John Debrunner (JIRA)" <de...@db.apache.org> on 2006/02/08 16:16:48 UTC

[jira] Commented: (DERBY-918) introduce a new test type to run junit tests from the current harness

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

Daniel John Debrunner commented on DERBY-918:
---------------------------------------------

Adding AllPermission to junit.jar is not required, Java provides the concept of privilieged blocks to solve this very issue.

The Java security model is that all code in the calling stack must have the required permissions to execute a restricted action.
Thus you see that junit.jar requires whatever permission your code needed.

However this is not a flexible solution, so Java has the concept of a privilieged block, kind of like the su command in unix.
Code executed in a priv block only requires permission for all code on the stack from the point of the restricted action up to
the start of the priv block.

Thus, say with derby.jar the policy file can grant access to read/write a database directory  but not grant it to the calling applicaiton,
thus ensuring the application cannot bypass the database security by reading files directly.

See the security section of the J2SE specifications for more details.

> 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