On testing...

Earlier this week I’ve received the Javalobby newsletter featuring an article by Antonio Goncalves on Why are we not using Java EE 5? While there is much to be discussed on the subject, I’ve been thinking about his statement on testing :
Testing a Java EE 5 application is definitely not as easy as a Spring application. We live in a world where everybody talks about test, but nobody really does it. Java EE 5 doesn’t help in this aspect.

I am not really sure he means Java EE 5 applications aren’t easier to test than ones written based on previous specification versions, because if he is, I don’t agree with that statement. If it is Java EE 5 promoting testing practices on developers, well that is probably outside of its scope anyways. But still that statement would probably have me being a double nobody, as I do use Java EE 5 (or at least on a few previous missions) and am among the ones that talk about testing, but also am definitively doing it! Yet probably not enough and have a really hard time getting developers on my team doing it properly…

Testing is surely a misunderstood subject. I even have been recently asked by some paper architect to draw a clean line between unit and functional tests! There is indeed much effort to be put in having developers to write pure unit tests. Ones that do not go to the database or the file system. Unit test that try to assess the completeness of the smallest piece of code possible. The Pragmatic Programmer’s book Pragmatic Unit Testing in Java with JUnit is a great source for developers starting with unit testing. I actually missed the exception on providing the empty array to the simple example used as introduction!
But after you a while you eventually really get into it. And it becomes as straight forward as testing your code manually… All tests should be run fast, within a few seconds and before every commit to the SCM system. Or at least on the ones on the module you just made changes to!

Integration tests, the ones that actually make sure that all your pieces work together in the intended manner, have also become pretty straight forward. These two sets of test give, in my humble opinion at least, developer a pretty good coverage of the application they are delivering. I currently use Hudson as my preferred continuous integration server, so we’ve installed a rogue server on our floor to run a real continuous integration as the company infrastructure team only provides nightly Cruise Control builds.

But this is the only point to which we’ve got yet in our 40 man big team… And, yes, of course we have quite some technical debt, and not only on the unit test front! But we really need to start improving on the system tests and more specifically functional tests. I am currently spending quite some time investigating on Model-based Testing. So I envisaged introducing ModelJUnit by Mark Utting into our test plans for the near future. I think that Groovy might be a good match there too, especially if we manage to get analyst to write these test themselves… Yet I think this might lead them to produce even more documents before they actually get going. Finite State Machine diagrams might be a start…
We are currently also still trying to introduce database deltas into the whole picture and maybe our own custom continuous deployment server, because of some delivery system the Agile coach for the company would like to put in place… But more on this later should we get there.

So this is my current state with testing. And while Antonio is probably not entirely wrong, I really hope that he is not right when he says that nobody really does it. What is your status on testing within your project or company?