A Foobject is Made of Green Cheese - Sense And Nonsense in Technical Discussion

I have been hanging out on certain "technical" mailing lists recently.

This is a sample of the type of argument I hear.The actual concepts have been replaced with fictitious 'FooBars' etc to protect the guilty (and more importantly, the innocent).

" ...I hereby proclaim a new style of programming. State and Behaviour will be consolidated in one entity, these will be called Foobjects.No, they have nothing to do with Objects, though this may sound similair to uninitiated ears. Don't ask me for exact differences; but if you unwashed heathen must know, here it is - allFoobjects are named with a name that is exactly 17 letters long. Now coming back to more important things, Foobjects will be used to model the domain.

Before you name a foobject, touch your nose to the floor and draw the holy name "foo" on the floor 3 times. The contact between the tip of your nose and the floor will put you into the right mental state to perceive the behavioral characteristics of the Foobject. And woe betide anyone who dares to name a foobject without doing this Holy Rite Of Naming. And of course this is just my opinion. Nobody can ask me questions or ask me to justify this logically. But this is of course better than all existing methodlogies of designing software systems.I won't show you any code but of course any code thus produced will be superior. You'll just have to take my word for it. Any challenges to this will be treated as a personal attack.I will soon write a FooFramework and FooBook. Keep your wallets ready. ..."

Now in contrast, some extremely useful stuff.

Dale Emery On Naming Test Methods(slightly paraphrased to remove context)

" The primary principle I use to organize tests is The Principle of Rapid Fault Identification:

If one or more of these assertions were to fail, what organization would lead me as quickly as possible to the faulty code? ... I might want three separate test methods so that if one fails, the others can still run and give me further information. If I write these as one test method, the first failed assertion aborts the method, and I never find out whether the subsequent assertions pass or fail.

A sub-principle I use is The Principle of Independent Utility:

If the results of the assertions might be independently useful to me in identifying the fault, I organize them into separate tests so that one failure doesn't prevent me from getting the useful information from the others. If the other results are likely to be just noise, I organize the assertions into one test method so that the first failed assertion precludes the others and suppresses the noise.

I use The Principle of Rapid Fault Identification also for naming: If this test were to fail, what name would lead me as quickly as possible to the faulty code? As an example , I might name three test methods something like this:

GameIsNotOverWhenFirstCreated() CurrentFrameIsNotOverWhenGameIsFirstCreated() NoScoreWhenGameIsFirstCreated()

I might come up with better names with a little more thought (or at a time of day other than 5:30am). For example, I'd like to write "NotOver" into a positive. Perhaps GameIsInProgressWhenFirstCreated().

The best test namer in the universe is Brian Button. I've studied his test names, and they tend to have three parts:

For example: GameIsNotOverWhenCreated() - Desired Result: Game is not over - Coordinator: when - Conditions: first created

These few principles have given a big boost to my testing."

This gem of a post justifies putting up with all the nonsense you have to wade through. This has already improved the quality of my testing 100%. The condition-connector-result naming format is extremely useful in coming up with good test names.