Testing Private Methods
Chris Frazier made an excellent point about my earlier blog "internal, not private" when he commented
"Testing privates bad. Testing public api gooood. Makes refactoring lots easier."
He's right of course, but of course I have A Very Good Reason. Well, no, actually I don't. I have a Poor Reason actually, but that's good enough for now.
You see, my reason for adding unit tests right now, this month, was that I had altered the interface to most of my stored procedures and hence many callers too. It was unavoidable in order to support unicode - I switched all parameters from varchar to nvarchar or ntext.
So, I could check my code manually by trying to get the CMS to run all these sprocs, or write unit tests to exercise them for me. Of course, I chose the latter.
But, I don't have time in this release to write unit tests for all my public methods. And in any case, many public methods don't result in any sproc calls. So I took the shortcut and simply called every method that called a stored procedure, regardless of it's visibility.
And of course, I got called on it. Good catch Chris, I should have put a big huge caveat in my original post. You know the kind of thing: "Don't do this at home Kids". Bad practice. Should know better, etc, etc.
