Personally, I'm hoping to achieve 100% test coverage firstly because I've discovered how dependent I am on having good test cases while working on HttpClient (most people don't have the detailed level of knowledge that Mike and Oleg do and thus aren't aware that a change will break some other section of code - NTLM is a regular victim of this). [...]
Any thoughts?
100% coverage is a nice goal, but how you get from here to there is pretty important. I like the philosophy advocated in Martin Fowler's "Refactoring" book: The most important tests are the ones that test the code with the highest probability of breaking. You can spend a lot of time writing tests for simple getters and setters, but they don't buy you much because there's not much chance of these methods breaking. It's much more valuable to spend that time writing one or two test cases for complicated methods or classes that are more likely to break (due to dependencies, complicated algorithms or specs, or whatever).
A test coverage tool is still valuable, though, because it can tell you which areas need more tests. You just have to filter the results a bit and concentrate on testing the complicated things first. When all the complicated code has 100% coverage, then you can go back and add tests for the simple stuff if you want 100% coverage for everything.
-- Laura
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
