ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruce Atherton <br...@callenish.com>
Subject Re: Selector Test
Date Wed, 04 Jun 2003 22:13:17 GMT
At 10:00 AM 6/4/2003 +0200, Jan.Materne@rzf.fin-nrw.de wrote:
>When writing the testcase for my selector I missed some functionality in
>BaseSelectorTest:
>- transfering properties from JUnit test class to the Ant test project
>- resolve the selection String ("TTTTT..FF") to filenames
>
>I have done that with a local org.apache.tools.ant.BuildFileTest class (like
>the TaskdefForMakingBed).
>
>Should I put that in the BaseSelectorTest class?

+1 for providing a way to translate to filenames. I'm sure that will be 
much easier to use when debugging a test failure. This should be easier to 
call from the test, though. Perhaps a new method in BaseSelectorTest that 
takes a selector and the selection string and calls assertEquals() the way 
you describe. If you could submit a patch against BaseSelectorTest for 
this, I'd be glad to apply it. If you could change the README while you 
were at it to describe how to use it, even better.

Regarding setting properties on the build that creates the test 
environment, I'm not sure I understand the necessity. Unit tests are quite 
static by design, to ensure consistent results. The more complexity you 
add, the more likely a test can fail in a way unrelated to the units the 
tests are testing. What makes you want to use passed-in properties?

Even if it is desirable to allow property settings to affect testcases, 
wouldn't it be better to add a setProperty() call in oata.BuildFileTest 
rather than creating a properties file? Something that called 
project.setUserProperty()?



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message