Home
Welcome to poju4s!
Poju4s is an experiment. Enjoy, fork, watch whatever :) If you're looking for an excellent scala testing tool may I suggest: scala test or specs
But we already have some Contributions :)
For some background about what this whole poju4s thing is all about check out the readme
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):
start up a repl
Next import poju4s:
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:
val spec
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:
val ex
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:
val bw
As you can see brief is just a shortcut for new BriefReport with Color
Running one test class at the time is all fine but the normal use case for test runners is to run all availabe tests. This is how to do that:
run all tests
Ok, cool, most tests ran, some failed. But which ones? This is how to print a summary over all tests that didn't succeed:
You may have noticed that the number of tests ran with a breakdown per status is an instance of class summary? To make this more obvious, lets save a result i a named variable and the get a summary from it:
saved run
As you saw it was possible to append the summary twice. This illustrates the point that one can compose a report from many elements. At this point there is only oe element available so we just added that element twice. Anyway, you get the point. Since this particlar double summary report is soooo useful we want to make sure we can run it again and again with minimum effort. Lets create oure own run-function:
custom report
Beyond cool :) lets cherry pick cherrypick a few tests to run from all tests available:
cherry pick
But no testrunner is complete if we can't see what really went wrong. Lets get more verbose output for the errors:
verbose output
With that the basics are in place. I have a ton of other ideas but first I will try to actually use this stuff on something real to see where it hurts.