harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: Tainting testing environment
Date Thu, 16 Mar 2006 15:37:49 GMT
Stepan Mishura wrote:
> Hi Tim,
> 
> I've reviewed my update and found I did a mistake - I occasionally
> substituted in two places Security.setProperty with System.setProperty (Of
> course I'll provide a patch to fix this). But this slip made me thinks how
> to solve restoring testing environment in case of security properties.
> 
> I think that nobody will object this is a good style for tests to clean up
> testing environment in the end of testing (I mean close all opened
> connections, remove created files, restore changed environment properties
> and so on). This helps to avoid conflicts between tests, when one test
> influences on results of another test.
> 
> java.lang.System class provides a ways to set and unset system properties -
> it has corresponding API. But java.security.Security doesn't have such API
> to unset security properties. For example, if security property say 'a.b.c'
> was not set in environment (i.e. has null value) and a test during execution
> define this property then it is not possible to unset it (assign null value)
> because Security.setProperty(String key, String datum) throws NPE in case of
> null 'datum'. Setting value to empty string doesn't looks good. Are there
> any other solutions?

The two things that spring to mind are:

 - create an internal API helper that we can inject on the bootclasspath
(or put in a bundle fragment) that will allow the test case to unset the
property.  Of course, this will make the entire test Harmony-dependent
so it will have to live with 'implementation' tests rather than 'api' tests.

 - move the test to a suite of tests that fork the VM on each test
invocation so you get a fresh environment every time (and therefore
don't have to tidy-up).  This will make the test a pure API test, but
will have performance overhead.

Regards,
Tim


> Thanks,
> Stepan Mishura
> Intel Middleware Products Division
> 
>> -----Original Message-----
>> From: Tim Ellison (JIRA) [mailto:jira@apache.org]
>> Sent: Wednesday, March 15, 2006 6:27 PM
>> To: harmony-commits@incubator.apache.org
>> Subject: [jira] Resolved: (HARMONY-200) 2 security tests must correctly
>> restore environment
>>
>>     [ http://issues.apache.org/jira/browse/HARMONY-200?page=all ]
>>
>> Tim Ellison resolved HARMONY-200:
>> ---------------------------------
>>
>>    Resolution: Fixed
>>
>> Stepan,
>>
>> Thanks for the patch, applied to SECURITY module tests at repo revision
>> 386061.
>>
>> Please check that the patch was applied as you expected.
>>
>>
>>> 2 security tests must correctly restore environment
>>> ---------------------------------------------------
>>>
>>>          Key: HARMONY-200
>>>          URL: http://issues.apache.org/jira/browse/HARMONY-200
>>>      Project: Harmony
>>>         Type: Bug
>>>   Components: Classlib
>>>     Reporter: Stepan Mishura
>>>     Assignee: Tim Ellison
>>>     Priority: Minor
>>>  Attachments: fixHarmony200.txt
>>>
>>> The following security tests set different system properties during
>> execution:
>>> javax/security/auth/PolicyTest.java
>>>
>> org/apache/harmony/security/x/security/auth/login/DefaultConfigurationTest.
>> java
>>> To avoid conflicts pervious values of system properties must be correctly
>> restored by tests at the end of testing.
>>
>> --
>> 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
> 

-- 

Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.

Mime
View raw message