Blah.Blah.Blog: October 2005 Archives

« September 2005 | Main | November 2005 »

October 27, 2005

Conveying intent in tests

Although I cannot remember who it was who first made this comment about my general approach to unit testing, but I'm indebted to them. The comment was something along the lines of "Andy, you have good test coverage, but what are the tests actually doing?". In short, what is the intent of the tests. From that time forward, I've paid a great deal of attention to how I name my tests better in order to convey the raison d'etre for the test: no more do my tests take the form of testValidateAddress1, testValidateAddress2 when they can be testValidateAddressFailsWithUnknownStreetType or testValidateAddressFailsWithMissingStreetName.

And over time, I've discovered a test's name is not the only way to convey the intent of the test...

I also use other general good naming practices to help those poor sods with the unfortunate task of following in the footsteps of my code and tests. In short, I look to convey my test's intent in the following four places, depending on which is applicable for the test at hand:

Test method name. 'Nuff said.
Extracted method names. Test sufficiently big to require the extraction of new methods? If so (and the test cannot be refactored into smaller self-contained tests), make sure these method names are also sufficient to convey the intent of each new method
Local variable names. Even if it's just something along the lines of "expectedFoo", it can make a assertEquals(expectedFoo, actualFoo); much easier on the eyes
Exception content. Recently I've found myself revisiting those times where I've been doing negative testing and asserting an exception thrown from a particular method. Up until now, I've normally just used the caught exception as proof of the test success, but I've started to experiment with a further check for the text of the exception message purely to assist in the test clarity. Something along the lines of:


public void testValidateAddressFailsWithMissingStreetName() {

  Address addressWithoutStreetName = constructFullyPopulatedAddress();

  addressWithoutStreetName.setStreetName(null);



  try {

    command.validateAddress(addressWithoutStreetName);

  } catch (ValidationException expected) {

    assertEquals("Address must have a street name", expected.getMessage());

  }

}

October 14, 2005

And the winner is...

Having worked as an IT consultant for a while now, I've had the opportunity to peer inside the corporate cultures of many of the companies playing at "the big end of town". Perhaps not surprisingly, the level of homogenity exhibited within these companies is truly remarkable. Much like supermarket shopping these days, you often have to make yourself consciously look around for the store's name as there is previous little difference between your average Coles and Safeways/Wollworths (apologies for the local references to non-Australian readers), a similarity presumably deliberate in it's cultivation.

A common attribute I see in every large corporate client I've worked for is the reward system for duties "above and beyond the call of duty" (which acronms quite nicely to ABCD :-)). On every project, there are regular presentations of some nominal gift (usually in voucher form) to those persons voted by peers or management seen to have gone one extra step in getting the project home.

But given you CannotMeasureProductivity, how is this selection of the project uber-workers achieved? As I'm sure you're all aware, it's almost always based on hours worked: the longer you spend at your desk, the higher your ABCD rating climbs.

So what are the downsides of this sort of behaviour? Principally, rewarding working longer hours sets up a feedback loop where staff feel pressured to work long hours to further their career. This has both long and short term downsides. In the short term, emphasis shifts inexorably from being smart enough to get the work done in the alloted time to no longer looking for more efficient ways of working. Where is the reward in taking half as long to get something done when the person who takes twice as long ends up with a weekend on the beach?

In the long term, the effects of prolonged periods of overtime are legion. Reduced morale, reduced productivity, poor health, increased stress on personal relationships are all natural outcomes of spending too much time at work.

What is needed is a way of rewarding people who work smarter, not longer. I'd be much happier seeing rewards go to the people who've worked hard to get their job done in the alloted time or who have instituted changes to allow the entire team to work quicker. But given that you cannot measure productivity, I'm quite frankly buggered to come up with a plan as to how this can be done properly - any ideas anyone?

October 03, 2005

www.crapraddialogs.com anyone???

OK - this is absolutely my last one of these posts. Please stop sending me these things!