writing readable & maintainable tests

Manning’s Art of Unit Testing is interesting in that it has chapters dedicated to the maintainability and readability of the tests. I didn’t read the whole book as most of it is about unit testing .NET code. (I’m a Java developer)

While these are pretty much all things I do regularly, I learned many of them through experience rather than starting out writing them that way. The most interesting along with some commentary from me were:

Readability

  • name your tests clearly – “test_method_1”, “test_method_2” are not useful names.  Better to say what is being tested.
  • use meaningful asserts – grouping your assertions into those with business meaning makes the main test easier to follow

Maintainability

  • avoid duplicate code – While this should be obvious, developers tend to be better at avoiding duplication in “real” code than “test” code.  It’s all code though.
  • avoid long and hard to understand tests – In my mind, the ideal test is as close to three lines as possible – a setup, a method call and a business assert.  There may be a few more lines.  But if there are too many, it likely the method doesn’t contain enough abstraction.
  • override toString – A great way to see the state of the object when the assert failes.
  • avoid specifying internals for dummy objects – Use stubs where you can.  Unless you are testing the interaction with an interface, you likely don’t need the granularity of mocks.

Anti-patterns

  • constrained test order – Despite the claims of TestNG, tests should remain independent of each other to make them as useful as possible.  It’s nice to see the author from the .NET world leans towards the JUnit philosophy.
  • shared state corruption – static state invites tests to rely on each other
  • multiple tests in same method vs a bunch of asserts for same scenario – I once heard a rule of thumb “one assert per test.”   I think the goal should be one scenario per test instead.  Having a bunch of asserts to check the state of a single logic thing makes sense.  Calling the same method with different parameters is crying out to be different tests.

What are your favorite tips on the topic?

eclipse 3.5 – four good, 1 bad feature

I’ve been using Eclipse 3.5 for a couple months now making it a good time to share the features that affected me the most – 4 good; 1 bad.

Getting started

Quick install with favorite plugins:

My Eclipse 3.4 workspace was starting to get corrupted making it a good time to make a clean break.  It wasn’t too time consuming to download/install Eclipse and create a new workspace.  I also installed the plugins I use regularly as I wanted them installed before switching to do development in the new workspace.
Sysdeo – For Tomcat with Eclipse.
Subclipse – For Subversion repository access.  The install of this one leaves something to be desired, but that’s not Eclipse’s fault.  it’s a license thing.
Ecl emma – For code coverage.
PMD – For static analysis.

Workspace setup:

1) Pulling in the source code from SVN is trivial.
2) I tweaked a few settings in the preferences.  I could create an epf file, but I hadn’t changed much in the old workspace.  This was a good opportunity to look at the new preferences in any case.
3) Then there’s the “what I need to do project” – it’s not committed to SVN (which is an accident waiting to happen) – but I have all the information in my gmail account or in my head.  The bulk of that project was a “todo.txt” file which I used to keep track of what tasks I wanted to work on for JavaRanch.  This file is now gone.  Which brings me to my favorite feature #1.

Features

Favorite feature #1 – Task Lists

This feature is awesome!  It replaced my “todo.txt” file for keeping track of stuff. (It’s different than //TODO or //FIXME because it isn’t necessarily tied to code.)  You can specify the status, a due date, categories and estimates.  I’m one of those organized types who likes keeping lists.  At work, I have a piece of paper I write on as I code with little things that come to mind, test cases I need to write, other tasks, etc.  At home, I was using the “todo.txt” file in Eclipse because I have less desk space than at work.  This makes the transition to an actual task list system a natural one and a pleasure.  I also started using gmail’s tasks around the same time.  They serve different purposes.  Eclipse for development.  Gmail for other things.  Did I mention I really like this feature?

Favorite feature #2 – “Open with”

When you use “open type” there is a drop down next to open that lets you choose the “open with” option.  This is really nice.  I can’t count the number of times I’ve tried using open type on a JSP to have it tell me my encryption settings aren’t correct.  I know the solution – open in a text editor – but that wasn’t the default before.  A minor annoyance, but nice to see it resolved.

Favorite feature #3 – Export/import JUnit results

Being able to send an XML file to co-workers about failing tests beats a screenshot.   Especially in terms of seeing the stack trace for “it works on my machine” type bugs.

Favorite feature #4 – Generate toString

This speaks for itself. And easy way to generate toString so it spits out all the fields is a nice time saver.

And the worst feature

Code formatting.  What happened?  This used to work intuitively and well in Eclipse 3.4.  In Java, it gets rid of my careful placed (for readability) whitespace between lines.  I checked the preferences and “number of empty lines to preserve” is set to one.  HTML is much worse.  If I format a bunch of lines containing one <input> per line, Eclipse turns this

<input type="hidden" name="action" value="moveAllSave" />
<input type="hidden" name="module" value="${moduleName}" />
<input type="hidden" name="source_forum_id" value="${sourceForumId}" />
<input type="hidden" name="log_type" value="0" />
<input type="hidden" name="log_description" value="bulk move from admin console">

into this
<input type="hidden" name="action" value="moveAllSave" /> <input
type="hidden" name="module" value="${moduleName}" /> <input
type="hidden" name="source_forum_id" value="${sourceForumId}" /> <input
type="hidden" name="log_type" value="0" /> <input type="hidden"
name="log_description" value="bulk move from admin console">

Huh?  That didn’t happen before.   I tried setting “never join lines” but it doesn’t take effect for HTML. I guess I’m not relying on the code formatting.  Unfortunate as it will slow things down.  But yuck.  Just look at it.

what happened to the java programmer plus certification?

Where did the Sun Java Programmer Plus Certification go?

[edit: July 12nd – it’s back now]

Background

This week I’ve blogged about Sun announcing a beta for the new Sun Java Programmer Plus Certification including why requiring programming is such a great thing and how it differs from the existing SCJP/SCJD.

Current links

If you Google “Sun Java Programmer Plus Certification”, the first link is currently the one to Sun’s announcement page.  (the second is to this blog)

Clicking on Sun’s link gives a “page not found.”  Sun also took the call for beta testers off their training page.

What’s going on?

With nothing posted from Sun about where this information went, that leaves us to wonder:

  • Did Sun not mean to announce this  yet?
  • Did Sun get cold feet and decide not to do it?
  • Did Sun realize the SCJP makes them a lot of money and they want to continue the multiple choice exam?
  • Did Sun get enough applicants for the July 22-31 beta and pull the information?
  • Did Sun realize people might be hesitant to take the existing exam when a new one is on the way?
  • What gives???

[edited to host image on alternate server]