Recently I was writing unit tests for some non-trivial methods on a few classes. I noticed that a lot of the tests were similar, but varied in terms of their input values and expected result values. Which then led to some refactoring within the unit tests to produce code with less duplication. Which led me to think about how I was going to test the test code I had just refactored. The thought process took me on to think about domains; in particular the fields of mathemetics or finance. My thoughts ramble here, so bear with me or leave if you like.
Let's assume we have a clever mathematician or actuary called Tess. Tess produces a formula for us to code up in a business object. My thought is this: "How would Tess test the formula in her domain?" We would attack a formula such as this with inputs and expected outputs because that's what our unit tests lean towards. But how does Tess validate the function? She steps through every part of the forumla, proving with known rules, that the formula is sound. She never uses inputs and outputs to verify the formula because she knows that this is statistically insignificant. That is to say, even 100 test values out of the possible hundreds of millions is insufficient to be considered a representative sample.
My conclusion after all this nonsense is that code reviews are under rated and far too infrequently employed. And, and this is what bites, we don't do them well enough. I know that some people do very good code reviews, and I am going to find out what they do that makes their code reviews more effective and complete than the code walkthroughs I've seen in the past.
No comments:
Post a Comment