Learned some things today to get something running with Clover. First off I learned that Clover uses it’s own embedded version of ant unless you specify otherwise. IntelliJ does a similiar thing, so you just have to tell it where yours is so it can use your version of ant.

<schedule interval=”60”>
  <ant anthome=”C:\apache-ant-1.6.5” buildfile=”cc-build.xml” target=”build”/>
</schedule>

This took me a little while to catch until I noticed the console was reporting running 1.6.2 and I only had 1.6.5 on the machine.

I had all sorts of problems getting the Clover html reports to run until I added fork=”yes” to the

Michael Feathers defined today his idea of a unit test:

A test is not a unit test if:

• It talks to the database
• It communicates across the network
• It touches the file system
• It can’t run at the same time as any of your other unit tests
• You have to do special things to your environment (such as editing config files) to run it.

Currently about 90% of the time I manage to meet these requirements with my unit tests. Still occasionally I write a functional test or an integration test. A lot of times I keep these separate and let Cruisecontrol run them. My plan is that all the true unit tests run in about .5 seconds.

One of my teams is finishing up a small project now with about 20 unit tests, but they all invoke only POJOs and depend on an in-memory implementation of the DAOs instead of starting up a hibernate session and connecting to the real database. While the project could use more tests, the tests get run fairly often because they are so fast.

Another of our projects has 700+ ‘unit tests’. They break pretty most of Michael’s rules. The connect to real databases and communicate across the network in test after test. The nasty part is they take 30-40 minutes to run. They never get run except by Cruisecontrol, and because they are largely large functional tests in reality they’re hard to debug and about 17 right now are failing and no one has had the heart to fix them in weeks. This of course says a lot about the project in general, but the lack of focus on true unit tests has always really hurt.

My sense is out in the real world, a lot of people who bother to write unit tests mostly write functional tests that often connect to a real database. No wonder they don’t see much value in them.

I had to review a proposal for reworking one of our major applications today. The application has a lot of inherent issues, but one of the interesting things was the solution involved a bunch of Stateless Session Bean Facades. Would have been a reasonable solution except they were describing an application that was to be completely contained in a single J2EE container. The system connects to a legacy mainframe application and a relational database. It of course doesn’t do distributed transactions. So I’ve got no idea why EJBs were proposed.

I’m guessing the Session Facade was proposed by default because a lot of consultants in the Java world are still selling EJB as the way to go. I half expect to get the ‘Enterprise’ development argument when I get together for feedback. The argument goes something like, well you wouldn’t want to build an application without EJBs, how will it scale. Core J2EE Patterns has been updated with a ServiceFacade pattern which allows for a POJOFacade Implementation. Maybe this is why I prefer the mentoring consultant model where the consultant’s major goal is to get a team up to speed.

I’ve been running through an on site use case class as we start to formally role out our Agile (Scrum based) methodology. The formalness of the rollout I find a bit over done, but buy-in is important. And generally management finds if easier to buy in if a consultant presents these ideas. Anyway despite having done a lot of use cases for requirements gathering in the past six years or so there’s always new techniques or tips to pick up. Some I got from the class today were:

• Use Simple Use Case Templates – I learned this the hard way after putting together elaborate Word templates in the past complete with nicely formatted tables and nested numbered lists. After many hours in Word cleaning up formatting I finally stopped using tables and simplified my numbering system as much as possible.
• Combining Alternative Paths and Error Paths – Apparently the instructor and I had learned the same lesson that it is really hard sometimes to define whether something is an Error Path versus just an alternative Path. Since the point is just to describe all the paths who cares if it’s an error path or an alternative path, just make everything an alternative path.
• Big Sketch Pads versus Projectors – My past experience has been using a projector with the use cases and going through each step with everyone in the room looking on. The instructor mentioned that she preferred to use a lot of sketchpads so more people could interact. She felt you got more of a visual sense of accomplishment and more of the important thoughts and details could be captured because everything doesn’t have to be funneled through the person at the one keyboard. I’ll have to try this out the next time I get a chance to do some use cases.

I’d never been really excited about setting up TestSuite classes like the classic AllTests in JUnit, but today I ran across an alternative. From a podcast at SwampCast, Jim Moore talks about a best practice being avoiding writing TestSuites.

Obviously they’re a bit of a pain and can be problematic to maintain, but often you need to break up at least the easy to run tests from the ones that are dependent on an actual database connection or a web GUI being up and running in a container. So you end up with something like GuiTestSuite that you only run with Cruisecontrol. Moore’s suggestion is to try to never write TestSuites. Simply use introspection in the various IDEs or in ant’s

task with the

tag. In order to avoid running dependent tests put them in another package like:

So if you have say some functional tests that run against say the actual web interface like JWebUnit you only run them if you include this package.