Poju4s – an attempt to make JUnit a bit more Scala friendly
Recently I felt like going back to basics of testing in Scala. There are some fine testing frameworks for Scala that I recommend that you use. Never the less I started thinking about what it would be like to make JUnit more Scala-friendly rather than rolling an entire new framework. Since I came down with the flu anyway I had some time when I was neither unconscious nor watching movies when I could toy with the idea. Long story short: I started the poju4s project on github here.
Poju4s obviously stands for “Plain old JUnit for Scala”
It is not much yet and it has some distance to go before being really useful but I think a few sparks of elegance have found their way into the code (or that is just the fever talking). Anyway, before I understand better than to make this stuff public. Without further due… here it is for what its worth:
A quick tour
At the moment I’m focusing on how to interact with JUnit from the REPL. Lets get a quick feel for what poju4s can do in this department. First of all fire up a REPL (I use SBT for this purpose):
Next import poju4s:
Now we’re ready to run tests from the REPL. Lets start by running an invdividual test. This consists of two steps:
- Mix in an interaction point for poju4s
- Run and render the output
Here we use InteractionSpec that is a spec in poju4s itself:
What happened here? By mixing in Basics into our plain old JUnit test it is runnable from the REPL. Basics just contains default choices for poju4s such as outputting information to standard out, adding methods for finding and running tests. The next question is what
brief is? Brief runs the tests one by one and outputs a green dot for each passing test and ends the run with a summary of the tests run. To make things a bit more interesting. Lets use an example spec with some tests that don’t succeed:
How pretty! :) Ok, as you see, since this is an experiment I can do whatever I want so adding silly colors came higher up on my list than things like being able to find and run all tests on the class path for instance :). For those poor bastards on some crippled terminal incapable of displaying such state of the art stuff like tty colors there is of course a way to avoid the tty control-codes to be sent:
As you can see
brief is just a shortcut for
new BriefReport with Color
I could show how pending and fixed works but that requires a bit of a scenario, perhaps a video so I’ll save it for later. Feel free to browse the source.
The obvious missing feature now is to be able to glob or grep for tests to run. It’s being worked on.
Please tell me what you think so far. Should I even bother with making the binaries available as maven dependencies?