This post originated from an RSS feed registered with Java Buzz by Brian McCallister. Original Post: Failing Test as Todo Feed Title: Waste of Time Feed URL: http://kasparov.skife.org/blog/index.rss Feed Description: A simple waste of time and weblog experiment Latest Java Buzz Posts Latest Java Buzz Posts by Brian McCallister Latest Posts From Waste of Time

I don't do test-first development, I do write-test-as-I-write-code-sometimes-before-sometimes-after development. Either way, I have found a nice idiom I have been using with the intercept library -- have a single TestCase for testing extent bugs, then move the test out to its appropriate place once fixed. This works well for feature enhancements and third party library bugs in particular.

For example, right now InterceptionBroker throws an NPE when attempting to wrap a java.lang.reflect.Proxy which can be traced back to net.sf.cglib.proxy.Enhancer.createClass(Enhancer.java:278). This is a very weird edge case for a bytecode generator so it is no real surprise that cglib gets angry at it. It is a pain for using dynamic mock objects though. So, a test case to note that we know it goes in. Its better than a bug tracking system as you can still run your regression tests and normal unit tests as the target excludes the failing tests, but you can get the known failures via ant todo.

Creating a failing unit test for a bug is a "duh" action -- I just happen to like the idiom here of seperating it out when it is an enhancement or third party library issue. For cases like this I am tempted to write the test to verify that the bug still exists and include it in the normal test suite so that it will fail if/when the bug is fixed in the third party library -- and I will know it has been fixed =)