Unit Test Code Coverage
A couple weeks ago, Michael Lucas-Smith posted about a code coverage tool that he published to the Cincom public repository. Jim mentioned it briefly and then everyone seemed to move on and forget it. People, wake up! This is one of the best tools published in the repository. There should be buzz about this. Think about it. We write tests to make sure our code works. Some of us do this well, some not so well. I thought I was doing great. I'm working on a project writing new code. I have been trying to make sure every Class has a corresponding TestCase, and that at least all of the api methods have corresponding test methods. I even wrote a utility to automagically generate the TestCase and stub test methods based on the protocols in my domain Classes. I make sure all my tests pass, or I stop and fix things before I move on. I figured I had things well covered. Wrong! After installing the code coverage tool, I could see where my deficiencies were.
One of the greatest benefits of the tool, is that it can show you branches of code not taken. Say you remember about some edge case, so you add logic to handle it. Then you write the test like I did, but just test for the common cases. With the code coverage tool, your method doesn't have 100%, it has some value in the middle. (If you didn't test it at all it would have 0%) So you browse to it, then click the coverage tab in the refactoring browser and it shows you (in red) the branches of code that were never called. This is huge. It's the edge cases with code that is rarely called that always bite us. I wrote it, so I interact with it a certain way. My users have no preconceived notions of how to use the software so they do things differently, and find places I wouldn't. But now, the coverage tool is helping me explore those hidden away places before my users. This is great!
One benefit that I hadn't thought of, but that I noticed immediately when I started using the tool, was that I found code that could be removed. It was untested, because it was not needed. I had changed the API slightly, but left the original methods or whatever. I was able to quickly identify code that could be culled. This is a huge benefit for maintenance. One of the big problems we have with one of our existing products is that they did the same thing 12 different ways, and left them all in there. So now, which to I use? Where do hook in to hack my new changes? By eliminating unused code early, I keep it lean and mean.
If you don't have very many unit tests, I can see how this tool could be less than exciting. Wow, only 3%, great.... I know from our legacy code that getting the coverage up is nigh onto impossible. But for anybody doing new development, this is huge. Sames, for example, with like 27,000 tests in Pollock could check if they're doing the job we all want them to be.
If you're doing unit tests in VisualWorks, you really should be using this tool!
One of the greatest benefits of the tool, is that it can show you branches of code not taken. Say you remember about some edge case, so you add logic to handle it. Then you write the test like I did, but just test for the common cases. With the code coverage tool, your method doesn't have 100%, it has some value in the middle. (If you didn't test it at all it would have 0%) So you browse to it, then click the coverage tab in the refactoring browser and it shows you (in red) the branches of code that were never called. This is huge. It's the edge cases with code that is rarely called that always bite us. I wrote it, so I interact with it a certain way. My users have no preconceived notions of how to use the software so they do things differently, and find places I wouldn't. But now, the coverage tool is helping me explore those hidden away places before my users. This is great!
One benefit that I hadn't thought of, but that I noticed immediately when I started using the tool, was that I found code that could be removed. It was untested, because it was not needed. I had changed the API slightly, but left the original methods or whatever. I was able to quickly identify code that could be culled. This is a huge benefit for maintenance. One of the big problems we have with one of our existing products is that they did the same thing 12 different ways, and left them all in there. So now, which to I use? Where do hook in to hack my new changes? By eliminating unused code early, I keep it lean and mean.
If you don't have very many unit tests, I can see how this tool could be less than exciting. Wow, only 3%, great.... I know from our legacy code that getting the coverage up is nigh onto impossible. But for anybody doing new development, this is huge. Sames, for example, with like 27,000 tests in Pollock could check if they're doing the job we all want them to be.
If you're doing unit tests in VisualWorks, you really should be using this tool!
Labels: VW testing coverage
0 Comments:
Post a Comment
<< Home