laziness, impatience, and hubris | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
If your classes do substantial calculations, it's useful to test the private methods that do the sub-calculations.
Otherwise, you'll probably end up doing more work to manage all the code coverage cases. That is, you'll need to do the same code coverage, but you'll have to reason out how to get to each submethod, and ensure you pass it the right parameters to ensure all of it's children get called. I'd just as soon call all the children directly, with valid, invalid, likely, and not so likely datasets, and ensure that all cases are handled correctly. If I know the sub-methods do their jobs, then testing the API becomes more of an excercise in confirming the behaviour of the API against the final set of business requirements, versus a frantic search for coding errors. If you only test the API, you also run the risk of your subroutines containing hidden flaws that cancel each other out. If you try to re-use or refactor such flawed code, you'll be in for nasty surprises later on...
But then again, testing is a lot of work in general, and if you refactor the internal methods, updating the test suite each time is a real pain. In reply to Re^4: "Accessors break encapsulation"
by Anonymous Monk
|
|