1

I am moving an application from JUnit 3.x to JUnit 4.x. Of course, my hundreds of test classes now need to statically import org.junit.Assert methods, or directly reference org.junit.Assert for each assertion.

Most of these test classes extend a custom test case wrapper class (let's call it CompanyTestCase) so it is feasible for me to do this

public void assertEquals(final Object expected, final Object actual)
{
    org.junit.Assert.assertEquals(expected, actual);
}

but that seems somewhat clumsy, and smells bad to me in general. However the little devil on my shoulder argues that this is one reason people create custom test superclasses in the first place.

Help me understand the best way to tackle this problem -- I really don't want to believe that this post is the answer, mostly because I want to believe that Java is mature enough not to require boilerplate changes of this type (DRY, etc.).

As @blalasaadri points out, it would be nice to extend org.junit.Assert, but, being a Spring/Mule application, the test case wrapper already extends org.springframework.test.context.junit4.AbstractJUnit4SpringContextTests.

Community
  • 1
  • 1
eebbesen
  • 5,070
  • 8
  • 48
  • 70
  • 1
    One option would be a search/replace on the methods, replacing them with a fully qualified name. As and when you edit tests, you could then tidy it up. I have also found used tools in the past to automate the process, [including on the Apache Commons Lang code base](https://issues.apache.org/jira/browse/LANG-824). – Duncan Jones Nov 26 '13 at 15:28
  • @Duncan [This post](http://stackoverflow.com/questions/264680/best-way-to-automagically-migrate-tests-from-junit-3-to-junit-4) even gives me the regex I'd need to do to get the conversion done, I'm just sad that I can't do something like a mixin to accomplish what I want to do. – eebbesen Nov 26 '13 at 15:32
  • 1
    You could of course have `CompanyTestCase` extend `org.junit.Assert` - that way no static imports are needed. Whether this is a nice solution is a different question though... – blalasaadri Nov 26 '13 at 15:41
  • @blalasaadri I've updated the question to include the (important) fact that my `CompanyTestCase` already extends another class, but if it didn't that would be a perfect solution. – eebbesen Nov 26 '13 at 15:47
  • 3
    Adding an `import static org.junit.Assert.*;` is not boilerplate—your wrapper method is. The import does not add anything to the runtime environment while your wrapper method does produce code which the JVM must process. And for what? Saving a line of source code that an IDE will add automatically? If you refer to the DRY principle you should think about what creating a wrapper method for each of the assert methods is. – Holger Nov 26 '13 at 16:09
  • @Holger I agree if I were creating the wrapper class solely for this purpose that extra code would be created, but I already have the wrapper class to provide other methods shared by the test classes. It seems to me that having to wade through hundreds of test classes (either manually or via regex) to add imports is an indication that I am now doing something wrong, or that something was done wrong when the classes were created in the first place. – eebbesen Nov 26 '13 at 16:56
  • 1
    Of course there was something wrong when the classes were created in the first place: the didn’t use JUnit 4 and static imports, most probably because these were not available at that time. But that should not bother you today as you are going to fix it. And that fixing/refactoring lots of classes might imply touching/modifying lots of classes is natural. Don’t judge over the quality of code by measuring how much you have to change to turn it into good code. – Holger Nov 26 '13 at 17:06

0 Answers0