db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel John Debrunner (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-918) introduce a new test type to run junit tests from the current harness
Date Wed, 08 Feb 2006 15:16:48 GMT
    [ 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


Mime
View raw message