Don't ask to ask, just ask | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
Right off the bat, that's a missleading statement. Code coverage tools can only tell you what lines are executed or not executed, I've never seen one smart enough that you can run it on a test suite, and have it tell you if all the side effects of every executed line of code is also executed. If I was running Devel::Cover on some unit tests I wrote, and it told me there was a conditional in which one branch wasn't getting run, I would never assume that just writting a test that executed that branch is enough to consider that branch "tested". I would also look at any state modified in that branch, and make sure that my test included any other code that refrenced that state after the branch. That's not just an important thing to remember about Code Coverage -- it's important to remember about any unit tests. I'm constently seeing people design/modify classes or objects which contain state, and write little micro-unit-tests which test each method individually, without ever testing "chains" of method invocations. The worst example I ever saw was an implimentatin of a glorified Hash that had methods like "add($key,$val)</code, <code>get($key), remove($key) and listKeys()" This is what the unit tests looked like...
The unit tests all passed, the code was handed off to the client, and the client send back the following set of tests *they* had written to prove that the damn library was a load of crap...
Just becuase you're code is getting executed, doesn't mean it works, or that all of the permutations of use cases are getting executed. In reply to Re: Is "ref($class) || $class" a bad thing?
by hossman
|
|