Interesting, but there is some danger in here as well. You could see Code Review as a different form of testing. Like a view from a different angle on the product. If you first look at the (unit) tests, don't you loose some objectivity as you start to think alike the one that wrote the tests (which is in most cases the same as the person that wrote the code)?
Also, I think tests are a better specification than prose written in an external document, but does not replace the in-code documentation, like javadoc. That should be clear for people maintaining the code. And code-reviewing is also to check if that is clear to someone without any prior knowledge. Especially in API's.
P.S. If anyone suspects that I'm having some fun inventing terms beginning with "test driven," I'll plead guilty as charged. :-)
Frankly, I'm getting annoyed by all the 'driven' and 'based' terms. Its popular these days but most of the times it's not well thought of. Sometimes even absurd, if you think about it. I hope that the force behind your code reviews is still your intelligence.
Nice post! And I thought I was the only crazy who demanded tests as part of code reviews coming my way.
I find this technique useful to the point that when my head begins to hurt reviewing some convoluted code, I write a couple of tests to clarify the "what-if" scenarios in such code.
@Arjan Don't confuse TDD with proper testing, the intentions are different. And some of us actually mean Test "Driven" Development. We use the writing of the test to guide our designs (with some intelligence too, we hope :)
well said. The test case is useful for understanding, and based on that criteria, we can prioritize test cases or even bug severe degree.
The test cases, including unit, integration testing, especially for user cases or external function or performance specifications, are useful to understand the software system.
If it is unit test cases, then it helps the understanding of the method at implementation level; if it is small integration test case, then it helps the interactions or short work flows among them; if it is a bigger even a whole integration test case, then it gives us a set of longer chain of work flows which in fact are a big picture of the whole software systems.
Test Driven Study Pattern :)
ReplyDeleteFor same reasons I start reviewing a code from headers, rather than implementation.
ReplyDeleteInteresting, but there is some danger in here as well. You could see Code Review as a different form of testing. Like a view from a different angle on the product. If you first look at the (unit) tests, don't you loose some objectivity as you start to think alike the one that wrote the tests (which is in most cases the same as the person that wrote the code)?
ReplyDeleteAlso, I think tests are a better specification than prose written in an external document, but does not replace the in-code documentation, like javadoc. That should be clear for people maintaining the code. And code-reviewing is also to check if that is clear to someone without any prior knowledge. Especially in API's.
P.S. If anyone suspects that I'm having some fun inventing terms beginning with "test driven," I'll plead guilty as charged. :-)
Frankly, I'm getting annoyed by all the 'driven' and 'based' terms. Its popular these days but most of the times it's not well thought of. Sometimes even absurd, if you think about it. I hope that the force behind your code reviews is still your intelligence.
Nice post! And I thought I was the only crazy who demanded tests as part of code reviews coming my way.
ReplyDeleteI find this technique useful to the point that when my head begins to hurt reviewing some convoluted code, I write a couple of tests to clarify the "what-if" scenarios in such code.
You might want to take a look at my talk on Sustainable TDD
ReplyDeletehttp://www.infoq.com/presentations/Sustainable-Test-Driven-Development
which covers similar ground.
@Arjan Don't confuse TDD with proper testing, the intentions are different. And some of us actually mean Test "Driven" Development. We use the writing of the test to guide our designs (with some intelligence too, we hope :)
well said. The test case is useful for understanding, and based on that criteria, we can prioritize test cases or even bug severe degree.
ReplyDeleteThe test cases, including unit, integration testing, especially for user cases or external function or performance specifications, are useful to understand the software system.
If it is unit test cases, then it helps the understanding of the method at implementation level; if it is small integration test case, then it helps the interactions or short work flows among them; if it is a bigger even a whole integration test case, then it gives us a set of longer chain of work flows which in fact are a big picture of the whole software systems.