Monday, January 5, 2015

Ignoring JUnit

In the past I have been against ignoring broken tests (usually accomplished by commenting-out the @Test annotation) - usually looking something like this:

//@Test
public void brokenTest()
{
  . . .
}

Generally when I have been involved in a project where this happens those tests get ignored for so long that they will eventually be thrown away.

Recently, however, overwhelming demand for this feature in my etl-unit testing framework (I.E., it was suggested by one developer and I liked it) meant I had to do some refactoring. When I was in the middle of  changing some code in a common module I wanted to get an idea for where I was in the bigger project.  I suspected JUnit had an @Ignore annotation and I was right.  So, instead of the above, this is what I had:

@Ignore
@Test
public void brokenTest()
{
  . . .
}

I liked this much more, for a few reasons:  (1) my IDE, Intellij IDEA, will run all the tests, but leave the ignored ones highlighted to call attention to them, (2) a simple search of the project will reveal everywhere this has been used, (3) this serves as a reminder to me of how much work I have left to do, and (4) I can do a full multi-module build to evaluate parts of implementation as I go.

I do prefer my own implementation for a few reasons.  The JUnit @Ignore annotation has an optional value attribute which can hold a reason for the ignore.  In etl-unit, the @Ignore annotation has a mandatory reason attribute which should contain a description of what is broken, etc (reason seems so much better to me - value is too vague).  Etlunit goes a step farther, however, and adds an optional reactivate-on attribute which holds a date after which time the test is no longer ignored, but rather than executing will throw an ERR_IGNORE_EXPIRED error, or a user-specified error or failure can be substituted, the latter being used when you would prefer for the test to fail rather than an error being generated.

I really like the reactivate date since these kinds of tests can easily be forgotten about, and when your continuous integration server builds start failing you will have a not-so-gentle reminder.

No comments:

Post a Comment