Danno Ferrin: Test Driven Patching. "My proposed solution is submit two patch files, the first one adds the tests and needed API changes needed to compile, and none of the new code for those APIs. The second patch actually contains the code that makes the APIs work." [almostperfect]
An interesting idea. Another idea, which would catch new code not having tests only, is to run coverage analysis before the patch, and then during the patched versions unit test run. If your new patch runs and there's more code that didn't run than before then there are probably no tests and a warning should be flagged up. You could even tie this to your automated build process if you have one.
Of course the ideal solution is to have some software analyse the code paths and then verify that unit tests cover enough of them. The reason that is ideal because if you can get that far then automated unit testing is trivial. I've only ever seen that implemented once so far, and I wasn't impressed. It's not an easy thing to do...
What other blogs are saying about this post.
5:30:26 PM 
|
