Wednesday, September 26, 2007

don't test for blocking conditions: an example

Matt Heusser quoted me on this at the Google Test Automation Conference. I've had this idea for some time, that many tests both manual and automated waste time explicitly testing for conditions that don't need tests.

I ran into one of those today. Or rather, my boss did. (He's not really a boss so much as he is an experienced colleague who has more conversations with management than me. Socialtext has very little hierarchy. )

We have a lot of automated tests that we created very quickly. Many of them have TODOs left over. I've been cleaning up the tests and implementing the TODOs.

One of the tests had a whole list of TODOs that had already been done, so I deleted the TODO list. My boss saw this and asked me why. In particular, one of the TODOs had been to create a record of a particular type, and my boss didn't see a test for this.

I pointed out that I had written an explicit test for sorting records of exactly that type, and three records of that type were created in the setup for the sorting test.

Had the record-creation failed, the tests for sorting would have failed. It's a nice economy of effort.


Grig Gheorghiu said...

Hi, Chris. One observation I have is that 'explicit is better than implicit' -- so even if you're creating that type of record somewhere else, the knowledge about that test is buried in another test. That makes it hard for example for a tool to parse all your test and generate the list of all your automated test cases. Especially when the creation of the records is done in your case in the setup method.


Simon Dugard said...

My first thought when I read this post was the same as Grig's. Sure, you might not need to have an explicit test, but it can make finding the problem much easier.


Brett L. Schuchert said...

In this particular case I think this might be OK since it deals with CRUD-related operations. It hard to write a fully-controlled, isolated tests for R that doesn't C.

The one general concern is whether the setup incidentally uses a given record type or it actually needs that particular record type. In your example, it's sorting that record type, so this test clearly tests the create path.

I agree that it requires "tribal knowledge" to know that there is implicitly a test using the C of that recording type, so this might be a case where some duplication is better.

Also, what happens when a particular requirement goes away and the test for it, which was testing something else, goes away? In the case of CRUD, this is probably not a real problem, so it's not too risky.

So I'm not convinced of the general principle, but I think it applies to this context.