@PicoUnit@ has been developed with a view to reduce the amount of setup within specifications, using Picocontainer to instantiate and pass in the required dependencies. One use is to locate test data from an external source and pass it in (this example is showing PicoUnit working with JBehave):
class ProductCode {
public final String productCode;
public ProductCode(String productCode) {this.productCode = productCode;}
}
...
public class ProductTest implements picounit.Test {
public void testProductHasNonZeroPrice(ProductCode productCode, Verify verify) {
verify.that(new Product(productCode.productCode).getPrice() > 0);
}
}
To me this use of PicoUnit is an example of the “Test Data Obscured” anti-pattern – the values being tested are unclear, therefore so is what the test is doing. A better example of how PicoUnit can be used is to create Mocks for you. Lets look at this normal JMock test:
public class FactoryTest extends TestCase {
private static final String ITEM_CODE="Bob";
public void testGetsExistingItemFromCache() {
Mock cache = new Mock(Cache.class, "cache");
Factory factory = new Factory((Cache)cache.proxy());
cache.expects(once()).method("get");
factory.createThing(ITEM_CODE);
//should returned cached instance
factory.createThing(ITEM_CODE);
cache.verify();
}
}
Half of the code here is simply setting up the mocks. PicoUnit aims to simplify this test by automatically creating the mocks and making it available to the test – the only code that is being hidden is the setup code for the test itself:
public class FactoryTest extends TestCase {
private static final String ITEM_CODE="Bob";
private Cache cache;
public void mock(Cache cache) {
this.cache = cache;
}
public void testGetsExistingItemFromCache(Mocker mocker) {
cache.get(ITEM_CODE);
mocker.replay();
Factory factory = new Factory(cache);
factory.createThing(ITEM_CODE);
factory.createThing(ITEM_CODE);
}
}
PicoUnit also abstracts out the actual Mocking API being used, although does use the ‘replay’ metaphor from EasyMock as opposed to JMock’s setting of expectations. Whilst this is down to personal taste, I much prefer JMocks way of doing things. It will be interesting to see if PicoUnit can support both mocking techniques.
PicoUnit is not currently available as a release.. For more information, contact @stacy {at} digitalcompulsion {dot} com@.
_Update_: You can grab the code now, from http://svn.adarwin.codehaus.org/
magpiebrain 
4 Responses to “PicoUnit”
I’ve seen a number of references to JBehave here, and while I’ve finally been able to locate the project, there’s not a lot of listed motivation behind it — what it’s about, who’s using it, and so forth.
From the looks of it, it’s a JUnit-ish thing, but perhaps I’m reading too much into it. If it is, why JBehave and not JUnit or TestNG? If it’s something different, what is it, exactly?
Well, firstly its not about writing tests. JUnit is currently being used to define code specifications by many people when developing with TDD. Whilst it is not completely unsuited to this task, the fact that a testing framework is being used to define and check expectations of code being written means that people new to TDD (which we really need to rename – for more on the issue see an “earlier post(magpiebrain – It’s time to drop the ‘T’ from TDD)”:http://www.magpiebrain.com/archives/2004/07/05/tdd of mine) often confuse the motivations behind TDD with testing itself.
JUnit does have behaviour that some don’t like – hence TestNG. It also has some limitations – hence Artima’s SuiteRunner. However these are still test frameworks, with the wording and focus on testing. JBehave is an attempt to create a tool focused on specifying code behaviour, with an appropriate language – it removes any ambiguity as to what it is being used for. It does also have some nice differences – for example the lack of a requirement to implement a class for your tests, and I’ve just finished a patch to remove the need for any prefixed method name. Support for Mocks (currently JMock) are also being built in to hopefully make mocking easier, and given its event-based nature it makes extension perhaps easier than JUnit.
JBehave is very much in its infancy right now, but can do pretty much everything JUnit can do – JBehave is being used to specify its own behaviour, rather than JUnit. The next task is to improve tool support – IDE plugins are by far the highest priority right now. Anyway, I’ll keep you posted as to its progress!
Hmm; interesting. I did read the earlier post you referenced (then, and again, now), but I guess I need more to really see where you’re going with this.
I accept that you say that what you’re aiming for is a verification of behavior and that JUnit is designed for testing, but after that, you’re losing me.
If you use JUnit with or without a mocking framework to test behaviour, I’m not really sure that’s a lot different from what you’re suggesting that JBehave is for.
Feel free to clarify or, alternately, I’ll just keep my eye on JBehave as it matures and there’s more information that’ll allow me to assess how it differs other than in description of intent. I’m curious to see where you’re going with this, but I don’t feel as if I’ve got much of an idea of that yet.
You can certainly argue that functionaly JUnit and JBehave have few differences – however twith JUnit’s emphasis being on testing, its language also revolves around testing. The biggest change is the change in language – but I really don’t think you can underestimate the importance of that.
It may be that JBehave will providde additional features later on that will further differentiate it from JUnit (for some the fact it’s being actively developed might be enough – JUnit seems a triffle stagnant). One area I certaily see some room for improvement in is providing closer integration with Mocking tools.
Right now, JBehave can do what Junit does but doesn’t have the tool support to justify a move away from JUnit at present. When the tool support is there it might make sense for people to move to it if they prefer the different language (it is suprising how more readable method names can be when you don’t enforce a prefix). If JBehave then goes on to make documentation easier, mocking easier, provides better tool support – then you can see more reason for moving.
Personally I think if JBehave could start working with something really advvanced (and unlike anything else I’ve seen out there) like “OO-Matron”:http://www.magpiebrain.com/archives/2004/07/27/oomatron (hate the name) it might be something really interesting.