Of course, excercising a path is only effective if the results of exercising the path are visible to the test harness. And that can be extremely difficult to achieve for code that is designed to trap the "should rarely occur" exceptional conditions. Which raises the question: "should you break encapsulation to enable testing?".
I am currently reading "Modern C++ Programming with Test-Driven Development" by Jeff Langr, and he takes the position that it is better to be able to test than maintaining some academic sense of purity of design, and that it usually isn't a problem. There are of course many ways to handle this. For example, we use macros that can make a static function global when building the tests.
Bugger "academic purity". His is the kind of sentiment I have previously heard from XP/Agile/TDD religious zealots. Unless you are only considering tiny toy applications, encapsulation is the key to large programs/systems which are reliable, maintainable, and high-performance.
I suggest you read books by someone that has been at the sharp end of writing commercially important code that has to work reliably and be extended for years.
Have a look at Jeff Langr's website, and see if you can find what programs he has written (as opposed to at which companies he was a mentor).
I've gotten this sort of critique before, and I understand where it comes from. I know a number of my peers to whom I might even subject the same condemnation. Personally I wouldn't expect someone to believe me unless I'd been in the trenches--and so I do for a couple years, do consulting for a couple years, back to a dev team, etc. The stuff I write is based on practical application. See
http://langrsoft.com/jeff/2012/09/the-consulting-legitimacy-cycle/.So yeah, about the last time that someone dinged me for spouting consulting BS, I knew it was time to move on. You'll notice no blog entries since August 2013; I've been too busy working full-time as a lead developer at Outpace Systems since. I'm writing Clojure code with TDD/unit testing (we're not quite so dogmatic as to insist it's all test-driven). Our product is largely invisible--it's an offer engine that processes 100,000s of events per day and crunches through that plus customer stats to produce better offers. It's been deployed to a very happy customer for about a year. The unit testing has made a big difference (although an insufficient amount of good acceptance testing has cost us a bit--which says that, of course, unit testing is only a portion of what you need to do to deliver quality systems).
As far as the TDD is concerned, it's paid off more often than not, though it can be a bit challenging at time (and we punt sometimes). It's not magic and doesn't solve all problems--that's some of the take on TDD I try to present in the book, how to approach it from a pragmatic stance. I've done plenty of non-TDD, too, and while I can survive that way, it's simply not as effective--or fun--for me and my colleagues, *particularly* on larger systems. The goal is to build a system that's maintainable and keeps the cost of change to a minimum. The ability to know that you can make changes without unwittingly breaking stuff (too easy to do) matters a lot, and is the main reason I do TDD. (You can get there with test-after, but I find it to be harder and less effective.)
You're correct, encapsulation is important, and core design principles matter a lot. That too is a personal emphasis I have on development. Some of the TDD folks buy into a heavily mock-based approach; I think mocks need to be used carefully, otherwise you get into some nasty dependencies of the tests on private details, and that can really squash your ability to refactor your code when you must. My recommendation is to minimize and isolate any such exposures--but it's still more important to know that the code works. So I allow certain elements to be inspected and possibly overridden. It's yet to bite me.
Regards,
Jeff
PS sorry about the delayed response, but I happened to stumble across this forum while doing a once-a-month-or-two search for my name. If you have a burning concern about any of this, feel free to email me in case I don't find my way back here soon. If you don't buy into any of what I'm claiming, that's ok too; we're happy with it, and it's not for everyone.