testing with system properties

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

testing with system properties

Michael Sokolov-4
I ran into a need to test some functionality that relies on system
properties. Writing the test was error-prone because the properties persist
across the jvm so if you set them in a test they leak across to other tests
unless you are careful about @After methods. It occurred to me it would be
nice if LuceneTestCase would detect this and yell. It could save all the
system properties before each test (or at least each test class) and see if
they are restored at the end.  I don't know if this arises much in Lucene,
but maybe in Solr?

-Mike
Reply | Threaded
Open this post in threaded view
|

Re: testing with system properties

Erick Erickson
See TestSolrXml.java for an example of:

@Rule
public TestRule solrTestRules = RuleChain.outerRule(new
SystemPropertiesRestoreRule());

Best,
Erick

On Thu, Aug 9, 2018 at 2:33 PM, Michael Sokolov <[hidden email]> wrote:

> I ran into a need to test some functionality that relies on system
> properties. Writing the test was error-prone because the properties persist
> across the jvm so if you set them in a test they leak across to other tests
> unless you are careful about @After methods. It occurred to me it would be
> nice if LuceneTestCase would detect this and yell. It could save all the
> system properties before each test (or at least each test class) and see if
> they are restored at the end.  I don't know if this arises much in Lucene,
> but maybe in Solr?
>
> -Mike

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: testing with system properties

Dawid Weiss-2
Erick already pointed you at the "cleanup" rule. This is fairly
generic, but if you know
the properties being modified you should still clean them up in @After or
@AfterClass -- this is useful for other people to know that you're modifying
them, if for nothing else.

Randomized testing package has SystemPropertiesInvariantRule which
will allow you to check if there's any property "leaking" from your
test. Some properties have to be excluded because various (system and
non-system) classes set them occasionally upon initialization.

Dawid
On Fri, Aug 10, 2018 at 2:13 AM Erick Erickson <[hidden email]> wrote:

>
> See TestSolrXml.java for an example of:
>
> @Rule
> public TestRule solrTestRules = RuleChain.outerRule(new
> SystemPropertiesRestoreRule());
>
> Best,
> Erick
>
> On Thu, Aug 9, 2018 at 2:33 PM, Michael Sokolov <[hidden email]> wrote:
> > I ran into a need to test some functionality that relies on system
> > properties. Writing the test was error-prone because the properties persist
> > across the jvm so if you set them in a test they leak across to other tests
> > unless you are careful about @After methods. It occurred to me it would be
> > nice if LuceneTestCase would detect this and yell. It could save all the
> > system properties before each test (or at least each test class) and see if
> > they are restored at the end.  I don't know if this arises much in Lucene,
> > but maybe in Solr?
> >
> > -Mike
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: testing with system properties

Michael Sokolov-4
OK thanks for the tips -- I'm glad to know this exists.

On Fri, Aug 10, 2018 at 2:03 AM Dawid Weiss <[hidden email]> wrote:

> Erick already pointed you at the "cleanup" rule. This is fairly
> generic, but if you know
> the properties being modified you should still clean them up in @After or
> @AfterClass -- this is useful for other people to know that you're
> modifying
> them, if for nothing else.
>
> Randomized testing package has SystemPropertiesInvariantRule which
> will allow you to check if there's any property "leaking" from your
> test. Some properties have to be excluded because various (system and
> non-system) classes set them occasionally upon initialization.
>
> Dawid
> On Fri, Aug 10, 2018 at 2:13 AM Erick Erickson <[hidden email]>
> wrote:
> >
> > See TestSolrXml.java for an example of:
> >
> > @Rule
> > public TestRule solrTestRules = RuleChain.outerRule(new
> > SystemPropertiesRestoreRule());
> >
> > Best,
> > Erick
> >
> > On Thu, Aug 9, 2018 at 2:33 PM, Michael Sokolov <[hidden email]>
> wrote:
> > > I ran into a need to test some functionality that relies on system
> > > properties. Writing the test was error-prone because the properties
> persist
> > > across the jvm so if you set them in a test they leak across to other
> tests
> > > unless you are careful about @After methods. It occurred to me it
> would be
> > > nice if LuceneTestCase would detect this and yell. It could save all
> the
> > > system properties before each test (or at least each test class) and
> see if
> > > they are restored at the end.  I don't know if this arises much in
> Lucene,
> > > but maybe in Solr?
> > >
> > > -Mike
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: testing with system properties

Michael Sokolov-4
I ended up using SystemPropertiesInvariantRule to enforce the presence of
cleanup in an @After method - I like the explicitness of that since, as you
say I know what the property modification is that needs to be reset. Thanks
again for the excellent tooling!

On Fri, Aug 10, 2018 at 7:51 AM Michael Sokolov <[hidden email]> wrote:

> OK thanks for the tips -- I'm glad to know this exists.
>
> On Fri, Aug 10, 2018 at 2:03 AM Dawid Weiss <[hidden email]> wrote:
>
>> Erick already pointed you at the "cleanup" rule. This is fairly
>> generic, but if you know
>> the properties being modified you should still clean them up in @After or
>> @AfterClass -- this is useful for other people to know that you're
>> modifying
>> them, if for nothing else.
>>
>> Randomized testing package has SystemPropertiesInvariantRule which
>> will allow you to check if there's any property "leaking" from your
>> test. Some properties have to be excluded because various (system and
>> non-system) classes set them occasionally upon initialization.
>>
>> Dawid
>> On Fri, Aug 10, 2018 at 2:13 AM Erick Erickson <[hidden email]>
>> wrote:
>> >
>> > See TestSolrXml.java for an example of:
>> >
>> > @Rule
>> > public TestRule solrTestRules = RuleChain.outerRule(new
>> > SystemPropertiesRestoreRule());
>> >
>> > Best,
>> > Erick
>> >
>> > On Thu, Aug 9, 2018 at 2:33 PM, Michael Sokolov <[hidden email]>
>> wrote:
>> > > I ran into a need to test some functionality that relies on system
>> > > properties. Writing the test was error-prone because the properties
>> persist
>> > > across the jvm so if you set them in a test they leak across to other
>> tests
>> > > unless you are careful about @After methods. It occurred to me it
>> would be
>> > > nice if LuceneTestCase would detect this and yell. It could save all
>> the
>> > > system properties before each test (or at least each test class) and
>> see if
>> > > they are restored at the end.  I don't know if this arises much in
>> Lucene,
>> > > but maybe in Solr?
>> > >
>> > > -Mike
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: [hidden email]
>> > For additional commands, e-mail: [hidden email]
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>