The answer is always in the code. Or is it?
Yes. And no.
The code depends on the data being a certain way. If the data is different, the code will fail.
This is the lesson that I learn (again) after an almost perfect experience of writing a test-driven solution.
I say “perfect” in that, test driven development is sold as a better way to program. In an ideal world, it’s a better way to develop because you write the tests first, which saves you time because the code works the first time. It’s the programmer’s equivalent of the construction worker’s statement “Measure twice. Cut once.”
Figure out the specifications first, before you write any code. You can’t write good tests for uncertain specifications, so the very act of writing the tests will lead you to find out the right information. This, in the end, should make it easy for you to build software that works the first time.
The time saving promise of writing unit tests is that they will save you from wasting your effort.
Does this pattern seem familiar: Write some code, then realize that you did it wrong, write some more code, then realize that you’re not sure about this other part, wait, go ask some questions, come back, re-read what you’ve written… and maybe write some more (buggy?) code… run some data through your code to see if it works… fix something… test it again… and so forth.
So recently, I wrote some tests, wrote some code that passed the tests, and my code worked the first time, on my local sandbox. Yay for me! I did it right, or so I thought. I then tested it on our development server. It didn’t work. What could it be? I start thinking about the differences between the environments.
It puzzled me for about a half hour. Then I took a break, participated in my favorite activities, and then had an ah-ha moment. I realized that the answer to my bug could be in the data. Sure enough, I returned to my desk and found that the real data was missing an array key that I had assumed would be there.
Lesson learned: Use real data for your unit tests.