Quo Vadis JUnit

For me JUnit is the most important library of the Java universe. But I think a new version of it is overdue. With it’s approach of having a method definition as a test definition JUnit is mighty inflexible and needs various hacks … sorry features, to do what you really should be able to do with basic (Java 8) language features.

If you aren’t sure, what I’m talking about, check out this article about ScalaTest. Something like this should be the standard for JUnit.

Of course you can implement your own TestRunner to get something like this going. But there are already many important TestRunners (SpringJUnit4ClassRunner anyone?) and they have the huge drawback that you can have only one of them.

Another alternative would be to just say good-bye to JUnit and use a different Testframework. But all these other Testframeworks don’t have the support from third-party tools that JUnit has, so I’d really prefer JUnit to evolve, instead of it being replaced by something else.

I was thinking about these issues for quite some time and actually brought them up on the JUnit mailing list, with lots of interesting feedback, but nothing happened. So when I met Marc, one of the JUnit committers at the XP-Days we started to discuss the situation, joined by Stefan, another JUnit committer and various XP-Days participants.

And as so often nothing is as easy as it seems. JUnit is a very successful library, but it also doesn’t offer all the features people want or need. This has the effect that people use JUnit in all kinds of weird ways, which makes it really hard to evolve. E.g. Marc and Stefan told a story about the latest version of JUnit where they learned that a certain IDE uses reflection on private fields of JUnit, resulting in a “Bug” when the name of that field was changed.

Therefore it seems, before one can make a change as big as a different default TestRunner, one has to revamp JUnit.

I envision something like the following:

  • gather the various features that others bolted onto JUnit, that probably should be part of JUnit itself.
  • provide a clean, supported API for those
  • apply gentle pressure and time for third parties to switch to the new APIs
  • behind that API provide a new more flexible way to create tests
  • profit

And since JUnit is an open source project and all developers seem to work only in their private time on it, we started right there at the XP-Days gathering stuff that needs consideration. I put the results in a wiki page in the JUnit github repository. Get over there and see if you can add something.

One Year Ago My Life Changed

One year ago I had an argument with my spouse. You might think “Boy, that must have been a bad one, if you remember it one year later!” But it was one of the best things that ever happened to me:

I was really angry and needed a way to vent, so I put on a pair of shoes, went outside and started to run. At that time I was really in bad shape. Definitely overweight. I felt how my belly fat sloshed around my middle and after like 500m I was breathing hard and had to walk for a while. Running and walking I needed about 20 minutes for 2.5 km and was quite exhausted afterwards. But I enjoyed it! My mood improved. And I did it again on the next day. And I’m running more or less every other day since then.

It changed a lot of things for me. Lost 12kg! Imagine you are carrying 3gallons of water around for every second of your life. And then you just drop them and walk around without them. It is an awesome feeling. I can run 4km in just a little over 22minutes. I can run 12km without a break. For some pants I still use a belt, but one year ago I used it because I wasn’t able to close the button. Now I use the belt because otherwise the pants would just slide down. I sleep better. My mood changed for the better. I can concentrate better.

I always thought running would be boring. But it turned out, running is the perfect sport for me: It gives you a time slot where your body is busy but you can think a lot almost without interruption. Thinking for one hour and a half about some difficult problem with nobody interrupting you … it doesn’t get much better, does it? Also running is flexible. You can do it always and everywhere: You can start at your door, or a hotel, there is just no excuse not to run. You can run on a hot summer day, in the rain, in snow and you need next to no equipment. Actually you can run with bare feet, if you are careful and it is quite enjoyable!

If you, like probably many readers of this blog, weigh too much and don’t move enough, change this NOW! Put on some comfortable shoes and start to run. Don’t run fast. Walk as much as you have to. Go as far as you can. Repeat tomorrow and three times a week after that.

Test your Dependencies with Degraph

I wrote before about (anti)patterns in package dependencies. And of course the regular reader of my blog knows about Degraph, my private project to provide a visualization for package dependencies which can help a lot when you try to identify and fix such antipatterns.

But instead of fixing a problem we all probably prefer preventing the problem in the first place. Therefore in the latest version Degraph got a new feature: A DSL for testing Dependencies.

You can write tests either in Scala or in Java, whatever fits better into your project.

A typical test written with ScalaTest looks like this:

  1. classpath // analyze everything found in the current classpath
  2. .including("de.schauderhaft.**") // only the classes that start with "de.schauderhaft."
  3. .withSlicing("module", "de.schauderhaft.(*).**") // use the third part of the package name as the module name, and make sure the modules don't have cycles
  4. .withSlicing("layer",
  5. ("persistence","de.schauderhaft.legacy.db.**"), // consider everything in the package de.schauderhaft.legacy.db and subpackages as part of the layer "persistence"
  6. "de.schauderhaft.*.(*).**") // for everything else use the fourth part of the package name as the name of the layer
  7. ) should be(violationFree) // check for violations (i.e. dependency circles)

The equivalent test code in Java and JUnit looks like this:

  1. assertThat(
  2. classpath() // analyze everything found in the current classpath
  3. .including("de.schauderhaft.**") // only the classes that start with "de.schauderhaft."
  4. .withSlicing("module", "de.schauderhaft.(*).**") // use the third part of the package name as the module name, and make sure the modules don't have cycles
  5. .withSlicing("layer",
  6. new NamedPattern("persistence","de.schauderhaft.legacy.db.**"), // consider everything in the package de.schauderhaft.legacy.db and subpackages as part of the layer "persistence"
  7. "de.schauderhaft.*.(*).**") // for everything else use the fourth part of the package name as the name of the layer
  8. ),
  9. is(violationFree())
  10. );

You can also constrain the ways different slices depend on each other. For example

  1. .withSlicing("module", "de.schauderhaft.(*).**").allow(oneOf("order", "reporting"), "customer", "core")

Means:

  • stuff in de.schauderhaft.order may depend on de.schauderhaft.customer and de.schauderhaft.core
  • the same is true for de.schauderhaft.reporting
  • de.schauderhaft.customer may depend on de.schauderhaft.core
  • all other dependencies between those packages are disallowed
  • packages from and to other packages are allowed

If you also want to allow dependencies between the order slice and the reporting slice replace oneOf with anyOf.

If you want to disallow dependencies from reporting or order to core you can replace allow with allowDirect.

See the official documentation for more details, especially all the options the DSL offers, the imports needed and how to set up Degraph for testing.

I’m trying to get Degraph into maven central to make usage inside projects easier.
I also have some changes to the testing DSL on my to-do list. And finally I’m working on a HTML5 based front end. So stay tuned.

And as always: Feedback including feature requests and pull requests is welcome.

Softwaredevelopment, Learning, Qualitymanagement and all things "schauderhaft"