Erik Hatcher wrote:
Done!
Test cases speak louder than anything else. And because there are numerous other test cases for <propertyfile>, making the changes empowered me to trust that all was well. Sorry - just a bit of XP philosophizing.
We need to set up a mechanism whereby we can have known test case failures committed to our CVS tree and a way to run them outside the normal "test" and "run-single-test" targets perhaps. This way Diane and others can contribute test cases demonstrating failures and we can fix them even quicker because we already have an easy demonstrable failure. Anyone have thoughts on how this should be crafted?
Erik
Hello:
You could have <exclude> filesets for the known failures and then have another target that does not exclude them? Quick and dirty, but does not require any changes to junit.
However, it might be worth making an enhancement to junit if this would be useful to enough people. My guess is that it might be. I would use it, for one :-) Of course, the danger is that it might be abused to "ignore" broken testcases or let them lie around for long periods of time. That could offend
XP purists...
Anyway, for example, you could have an annotation either in code or in javadoc about "known broken" testcases and have a way for the reflection code that finds all of the "testXXXX" methods to omit such testcases or not.
Just some thoughts,
--Craeg
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
