The Difficulty With Custom @Rule in JUnit 4
@Rules are no doubt a good idea. But let me first be my usual critical self. The way they were rolled out as part of the 4.x train makes The Herminator look like Master of Festivities as Buckingham Palace. First off, what on earth is the basis of that name?? Well if you thought it was just misguided and would quickly give up its secrets in the only temple of learning [Einstein] humankind knows: example, you were wrong. Why? The only example for something like 3 releases was a TemporaryFolder. Go ahead, try and put those together in a conceptual space that is going to make sense to anyone, I dare you (that SNL skit sending up Clint‘s Super Bowl ad was pretty awesome, still on the brain).
The idea of a temporary folder, though, that you can just declare, fill with crap, and leave for someone else to cleanup is dreamy. Not only because, as Beck likes to point out, we are lazy (devs), but because the most pernicious stupidity about tests, that, unfortunately, is still as pervasive and contagious as foot fungus, is that they take time. I love tests that take no time. Mainly because they put the lie to that, but also because it keeps your focus on your own code.
I was writing some code over the weekend using neo4j (more on that) and one thing I already LOVE about that thing is they have a super simple way to make an embedded database so you can write most your code inside basically barren JUnit tests that run in milliseconds.
However, there is the small matter of setting up the db, then tearing it down, oh, and the db, in its embedded form, needs a folder.
Enter rules (read, pluggable custom resources).
First I found a bunch of people talking about making rules by implementing MethodRule, but that is now deprecated . (One of the hazards of coding by google..) But then, surprise, now I can be sunny self for a minute, I did a bit more searching to see what the successor was, got a name, searched on that and it led me to the project. Decided to clone it and look at the source. Now there are a bunch of examples, including one called EmbeddedResource. The JavaDoc, however, shows a usage scenario where you instantiate it in place and provide Before and After implementations. Damn, the sun wasn't out for long. This is when annotation-based programming becomes so stupid its not even like reverting to Structured Programming, it's going to give you Linear Programming nightmares. But, it gets worse. I figure out that I am going to make my own rule by simply extending EmbeddedResource, then setting up and tearing down the db, and starting and finishing the transaction. That all goes great, but get this: I need a temp folder, so of course, I declare a Rule for one in my Rule class and inside my Before, that folder has not been created yet! Yeah, that's right, we are in that special circle in hell that the Spring guys got trapped in with their test stuff: where you don't even know when each Before and @After is going to be called. Someone else noticed this, it was a bug that they supposedly fixed in 4.8, but is broken again in 4.10, read about it here.
This is still the right way to do this, but alas, as usual, the framework took years to grow more than one example and even then, the road to extension is a potholed, untraveled cart path.
Update: Stupid resolution #___: you really can‘t put a Rule inside a Rule. This makes me think that the one example of a neo4j Rule I found was one that simply extended TemporaryFile. I‘m old school: I hate violating the most basic rule of OO programming [Is a graphDatabase a temporary file?]. So for now, I have to have 2 Rules, and pass the folder from the one to the other. The problem with this approach is that get this: by the time @After is called on my temp db, the folder is already gone so database.shutdown() throws a file not found exception! [Insert circus music here….] I thought I had this beat because I added a getter and put logic in there that waited for the first call then created the db there, but still got the error about the folder not being ignited.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)