Another post from Paul Bourdeaux, this time on the bias you have from knowing how the code works, and how it affects your tests.
As I’ve been there before, I agree with the premise. When you write tests, you have a set of knowledge and assumptions that you use. This knowledge includes the code you know (if it exists), and obviously impacts your tests. In extreme cases, you may see that people duplicate production code into the test code – to cut corners, to make things easy, a number of reasons. Of course, it wouldn’t have happened if the code wasn’t there in the first place.
However, this is not the complete picture, it’s not just Test-First vs Test-After. In the example Paul gives, checking for a leap year, the real problem is not what was written first. With the same understanding that the developer had when he wrote the production code, he could write the tests first, and arrive at the same results.
What could have changed this was understanding of the problem domain. If the developer knew how leap year works, he could have written the tests first or after, and he’d get the correct result. Personally, I like the test-first approach, because it makes you think about what you want, and may cause you to question what you know about the problem domain.
And this is my point: in order to write better software, developers need to know about the domain. And organization need to understand that, and allow (and make) developers meet the users of the software. I was in a project that had 4 layers of separation between the user and the developers, and I think that this is the usual minimum. It can grow to a lot more, and with any abstraction, there’s a translation and translation errors. Agile methods work by removing some of these layers, and the more people talk the same language, understanding each other, communicating, there’s a big chance the software will work.
Do you want to start today? Ask someone from marketing/sales/support to review the tests (Yeah, they won’t understand it. That’s why you need better naming for your tests). Go over the different scenarios, ask if there’s something missing. And, yes, YOU need to get those people to your desk, it’s your responsibility.
