Geeks With Blogs
Ned's Notes

Good attendees learn from the speaker; this week I was reminded that good speakers learn from their audience. The NJDOTNet (http://www.njdotnet.net/) group was fun (My thanks to Jess Chadwick for the invite!), a lot of sharp, involved people (and one wise-aleck to keep things interesting).

NJDOTNet’s feedback shows I need to clarify a number of points. They are the relationship between the iterative development process and test case selection, the recommended number of asserts per test, and the relationship between BDD and analysis.

Iterative development (Red, Green, Refactor) is a process for developing code; it has no bearing on the choice of test cases. Red means write a failing test, ensuring the test can catch failures, that is test your test. Green means make the test pass, as ugly as you need to be. Refactor means clean up, so you can move on to the next feature. As a participant pointed out, it is possible to regress the system such that a test always passes, still I think it more likely to initially write a test which can never fail.

The TDD community recommends one assert per test to simplify debugging. Their goal is to fix a failing test in a single code, test cycle. If a test has multiple asserts then more than one assert can be broken by a given set of code changes. Since failed asserts throw an exception, a failed assert stops the test, preventing any other asserts from being evaluated. This can result in fixing one failed assert, only to find another failed assert in the same test, preventing the test from passing.

Personally, I haven’t paid too much attention to my assert count and am moreover in full agreement with the TDD community that each test must verify exactly one behavior. When I do use multiple asserts in my tests, I rely on careful choice of assertion failure messages to facilitate debugging. I’m not that concerned if I need multiple code/test cycles to fix a failing test, so long as failed asserts have informative messages. As they say, your mileage may vary.

BDD blurs the line between analysis and coding. An early discovery of the inventors of BDD, was that they were using the language of business analysts to name their tests, a very good thing! http://dannorth.net/introducing-bdd At the very least, BDD can replaced low-level design documentation with executable specifications, which are much more likely to be up to date.

Till next time.

Posted on Sunday, May 17, 2009 11:46 PM | Back to top


Comments on this post: Speak to Learn

No comments posted yet.
Your comment:
 (will show your gravatar)


Copyright © NedsNotes | Powered by: GeeksWithBlogs.net