I'm not really into the one assertion per xUnit test method dogma; I have sympathy but run with the fox as well as the hounds. But when I go for multiple assertions in a method, I do like to use the optional message string. However I often see assertions that I do not like:

assertTrue("Some widgets are missing", testee.isAFullWidgetCompliment());

As far as reading the code is concerned the message (to me) says:

I assert that some widgets are missing

It's the opposite of the actual test. Because the above (unfortunate) convention is so common I avoid writing the natural message "All widgets are present" in favour of the unambiguous

assertTrue("All widgets should be present", testee.isAFullWidgetCompliment());

Thursday, September 29, 2005 | Permalink | 0 Comments

I've been musing on bureaucracies recently, from the point of view that those who say that they are a necessary evil are half right. Seth Godwin notes that members of the bureacracy seek to be beyond reproach. In other words the prime objective is to avoid failure (or at least avoid being blamed for failure). As the bureacracy "learns" from mistakes, more and more procedures are instigated to avoid repeating failures. Very soon the cost of avoiding failures rises above the potential cost of the failure. For example consider the development team (*) 8 months into a project and four months away from their first scheduled release that have not written a line of code because no-one dare make a decision on what technology to use. * real story, but at a friend of a friend's company

Monday, September 19, 2005 | Permalink | 1 Comments

We chose to test drive a maths problem during Tuesday's Extreme Wednesday session (don't ask) mostly as an exercise in playing with Ruby Idioms and Emacs. The problem was calculating the maximum number that could be obtained by summing consequtive numbers in a list. It's clearer with examples: For [1,2,3] the answer is 6 [1,2,-2,1] the answer is 3 [3,3,-1,3,3,-20,8] the answer is 11 We could only think of a brute force answer: sum all possible combinations. Afterwards Anthony tried a solution in a paper he had on that subject which was something like (in Ruby)

def max_consecutive_sequence_in_array(arr)
 result = sequence_sum = 0
 arr.each do |x|
     sequence_sum = [0, sequence_sum + x].max
     result = [result, sequence_sum].max
 end
 return result
end

That passed all the tests, but we could not figure out why it works. Bothered by this I fired up Excel on the train this morning to see the algorithm in action; I got the whole thing working in a minute or so and was staring at the numbers wondering how this was going to help when suddenly the solution made sense. So what am I getting at? Making the spreadsheet did not directly lead me to the solution, yet somehow making the algorithm more explicit by tackling it in a different way. It reminded me of the "Team Therapy" workshop with Dave Hover and Tim Bacon at XP 2005. One of my stories was of a team attempting XP but being foiled by one very obstructive team member; let's call him Andrew(not his real name). I had reflected on those events previously, and thought I could understand Andrew's point of view. It wasn't until the second telling of the story during the workshop that I realised just how shoddily he had been treated around the time of the team's formation and how, as a team, we had failed him. I already knew all the facts but I did not fully understand their implications until I told Andrew's story to other people.

Thursday, September 15, 2005 | Permalink | 0 Comments