Review: The Art of Unit Testing

by EvanJPalmer

I’ve recently started my first meaty commercial project with unit testing. I’ve been doing it for a month or so, maybe six weeks I’ve already been saved by my Unit Tests several times, and found my productivity increase dramatically.

I never want to go back to writing without tests again.

My team currently has mixed experience with Unit Testing. We have a developer with a lot of practical experience, to a developer with little to no knowledge of the subject.

I’ve had interest in unit testing for a while, and implemented it (poorly) on a small brochureware site while back. I read the book Working Effectively With Legacy Code by Michael Feathers when I started working on the current project because… of the ample crap code, so I had some ideas about testing in general. I think I learnt a lot from that book, but failed at implementing anything of any real use out of it, for several reasons (mainly a huge turnover in staff at the time).

For someone with no real experice, this book was really excellent. To me it felt like a long chat with a developer much smarter than me, and by that I mean, it seemed casual but knowledgeable and to-the-point. I felt that it really pointed me in the right direction, pointing out possible mistakes (that I was actually making), ironing out reasons for tests, and informing me of the best practices and conventions.

I’d recommend this book highly for someone starting out with Unit Tests (not necessarily TDD). I believe that it goes well with hands on experience, and as it’s not a particularly long book, you can get through it in the first few stages of the project.

Some other items I’ve found helped me along the way in addition to the book were Object Mothers and this TDD Code Kata. Very nice stuff.

If you haven’t seen it – Check out Ian Cooper’s NDC talk on “TDD: where did it all go wrong” which highlights how Dan North’s BDD reminded us what Kent Beck was trying to say. – TDD unit tests test behaviours not explicitly classes, methods or internals.
The more tests which know about the internal workings – the less willing you will be to refactor.

That’s really interesting re: testing behavior, not classes. I tend to have one test class for each of my classes, and I prefix the names of my individual tests with the name of the method I’m testing. Which I think may be the wrong thing to do. So I’ll have to rethink how I’m doing this.

I was watching a video by JBrains the other day who also pointed this out:

There’s absolutely nothing wrong with testing at the class/method level if they are critical to security or encapsulate complex algorithms. Then go to town on equivalence partitioning and boundary value analysis.

But the general guidance is to test “outside in, not inside out”.
The point when tests become a barrier for change, is when you stop being agile.
Keep up the blogging – I like your style.