A few days ago I attended a webinar from Agitar on JUnitFactory, that is an experimental test-generation service intended mainly for universities and research institutions. The aim of the service is to generate unit tests automatically starting from the code that requires to be tested. To keep the story short: unit tests retrofitting for legacy code.
I was waiting for the webinar to be published, but nevermind, this is what I remember about it.

To be honest I haven't tried JUnitFactory yet, I have got an invitation from a friend of mine, so I was curious to learn more from the webinar. On the other side of the wire there were Alberto Savoia and Kevin Lawrence.

The basic capability of JUnit Factory is to analyze your code and generate unit tests according to its semantic. The interesting thing that I have noticed in the webinar is that the tests that are produced are not only an empty scaffolding that you have to manually manage, but a good quality unit tests suite, sophisticated enough to understand for example the appropriate value to feed into a regular expression parser. Beware that the generation is not done on your machine, but on Agitar's servers: your code is uploaded to them and tests are sent back through the plugin. Therefore, you better not use it on your proprietary confidential code, but it's perfectly fine if you are working on an open source project.
JUnitFactory is fully integrated with Eclipse, hence its usage is pretty natural and it's also considerably fast: Alberto Savoia generated all the unit tests of a sample application several times during the webinar, making some modifications to the code between each generation and despite it was a simple application, I was impressed by the smoothness and speed of the overall approach. There's a post in Agitar's online forum about using JUnitFactory on a known mid-size open source project and the numbers are quite impressive. On JUnitFactory's site there is also a flash demo that gives you a more precise feeling on how the tool works.

Other interesting considerations emerged during the webinar:

• There are some nice helpers that Agitar provides. For example, they can be very helpful as factories if you want to control the way your objects are built for the unit tests.


• JUnitFactory's Eclipse plugin includes adequate code coverage information through the Agitar JUnit Runner.


• The tool seems to be not very good at GUI toolkits like Swing, but if you practice some reasonable design practices (like TDD itself - see beyond for more considerations about it), the situation could be much better (e.g.: JUnitFactory should work pretty well on controllers and domain objects).


• Today JUnitFactory works with java only, while C# is on the roadmap (but unfortunately there is no current plan for other languages like ruby).

I have to confess that I have attended the webinar with some prejudice: practicing TDD every day I take great care of my unit tests and it sounds pretty weird to think about them as a disposable artifact, something that you should better automatically generate. It's also worth noticing that, while in the agile community it is by now commonly accepted that TDD is more a design practice rather than a testing practice, where tests are a second order artifact that constitutes your non regression safety net, in the bigger world beyond the agile sphere unit tests are still seen as an ideal practice: everybody talk about it and take it for granted, but in reality they are seldom implemented.
So I was thinking: "Wow, this can be great for mammoth organizations that aren't practicing unit testing in any way, but how can this fit with an XP team, for example?" And I ask them about it. The answer was what I expected to be: teams practicing TDD will still TDD their code and may use JUnitFactory in the end for several reasons. One of them could be the fact that via JUnitFactory you may discover cases that your tests didn't cover.
I think that this idea makes sense, even though I still have some problems to think that after crafting carefully my code I'll throw away all my unit tests to rely on a suite that is automatically generated by a tool. There are also some areas that are worth to consider:

• If you need to refactor deeply your code for whatever reason (e.g.: new requirements are inducing structural changes into the code itself), there may be situations where you would feel much more comfortable dealing with the unit tests manually rather than regenerating on a code base that because of all the structural changes is not that solid anymore. What I mean is that the tool generates unit tests according to your code, while the existing test suite in some situation gives you more information than just the code itself.


• Connected to the precedent, some code is best documented by its unit test. The shape of the unit tests, designed carefully by the developer, has a value in itself. If you throw it away, you loose that value.

The title of this post is obviously a provocation, a loose and biased metaphor that resembles these doubts. Overall I think that JUnitFactory is darn interesting, also for agile teams, and even though it may not change dramatically your day-to-day practices, it is worth thinking about it.

Finally, JUnitFactory uses AgitarOne behind the scenes, Agitar's product in support for unit testing practices. I think that this is a very smart move for Agitar: by releasing the technology to the public in a different way, they are getting good publicity and having a lot of feedback at the same time. Of course, if you are really serious about this approach, your company should consider buying AgitarOne's license.