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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
