Good article, Steve. I've been thinking about testing software, unit testing and so forth. I've mentioned before how learning unit testing I believe got me my current job, so I don't take this topic lightly. However, now that I've done it for a couple of years I've come to realize that its too easy to test for the wrong thing or waste a lot of time just writing ineffective testing code. For example, even though having taught myself unit testing was important in my landing my job, I've discovered that they really don't do much unit testing here. (My group does, but I think we're alone in that.) Within 6 months of my being hired we started trying to achieve 100% code coverage. Trying to do that means you write a ton of unit tests, but windup writing test code that shouldn't ever have been written. I wrote a lot of unit tests that verified assigning a property to some value would return that value. Well, of course it does that! But, we were on the mistaken quest of achieving 100% code coverage. That can get you to having testing nearly every code line (we found it impossible to completely get to 100%), but you can still not have tested the code wisely.
I'm coming to the conclusion that there must be a more intelligent, or let's say thoughtful, way of testing your code. This involves testing extremes, like huge numbers or strings, large data sets and so on. At this point I consider it more art than science. I've taken a good Pluralsight course on it, but I pay for these courses which my employer doesn't provide and at least at this point my fellow developers and DBAs don't pay for themselves. Even so, I don't think this course covers it all. There's room for improvement on my part and others.
Kindest Regards, Rod Connect with me on LinkedIn.