Virtual Surreality

Should it be assertEquals(expected, actual) or assertEquals(actual, expected)?

This discussion came about because at the Chicago Code Camp, Jim Suchy from 8th light was demonstrating TDD in JavaScript by building a simple unit testing library. One of the methods he created was the typical assertEquals. In the code on github he had a signature of assertEquals(expected, actual) while during the demo he swapped the order, and I pointed out that the original was what I would have anticipated. He commented that there was an interesting discussion about it at his office a few days before. I’m interested to hear more about it, and I tweeted that I was inclined to get a debate going about it just to see what the different rationales were. This post is a collation of thoughts and opinions to date.
Read more…

My colleague Jay Fields recently blogged about the value of test names.

We had a little discussion about it yesterday on IM. Here’s a summary.

Josh Graham

I feel the test name is important for two reasons:
1) it is intentional programming – a neural pathway is established in your brain as you write the name of the test method so your mind tries to think about what the hell you are trying to achieve by doing all that typing
2) for those test consumers you speak of to get a sense of the behaviour of the system as specified by the stories and high level acceptance criteria

Jay Fields

2) [is] fair enough. Before introducing expectations on any client project I’ve brought it up as “what do you think about” and let the team decide. The last thing I want is an idea to be branded as bad because the wrong ppl used it
1) I think is based on the person. I always found it 10 times harder to write a sentence, I just want to get to the code but, I’m crazy for making the code intention revealing

Josh Graham

Picking a reasonable moniker for the test name is useful too, when something breaks (particularly if it occurs often)… “That #$%#$%! shouldRejectLostOrStolenCard test is failing again – must be the clearing house API has changed or they’ve crashed once more”.

Jay Fields

yeah, that’s an interesting point
wish you would have replied with that one, I’d have put it in my entry

We then talked about how to attach a moniker to the test on different languages – method names in Java being the easiest, while anonymous inner classes being a way to do so without having a moniker (other than perhaps a comment) at all.

I still contended that a method was a reasonable level of granularity to contain a test and use the method name as the moniker. A method (it’s declaration and its body) is location independent – it can be moved around in its module and you can still find it and its moniker appears in the abstract syntax tree so it’s very easy to find when using an editor that maintains an AST.

Jay’s responses to my scenarios in which this proves useful assume a short TDD cycle and also good developers.

So, while the test name may be superfluous in some cases, I don’t mind the extra mental effort of summarising the intent of the test into its name – and if that is overly difficult or not needed (both of which are plausible) then a banal label like enclosing the test in a method called “test1″ is a small price for me to package it up in a manageable, easy-to-find chunk.

YMMV.