On Fri, 02 Dec 2011 14:06:00 -0500, Adam <[email protected]> wrote:
Your presumption is that someone is required to run tests just to ensure that their class definition is what they expect. If I define a class and it's concrete (because I've defined everything), and later someone changes the parent class, my class is no longer concrete (it no longer conforms to my intention, despite having no way to actually *declare* my intentions in some explicit form). A programmer should do testing, but may not (does D require a programmer to test? No). You are implicitly testing the *definition* of a class, rather than it's *use* (or accuracy, or stability, etc). Testing or not testing is TANGENTIAL to the issue. Assume that someone is not going to do unit test declarations (and do so without running off on the wild notion that it's "bad programming," because we've already established that). WITHOUT that test, I cannot *know* that my class *IS* what I originally defined it to be.
You're being a bit dramatic, no? The code didn't compile, the compiler caught it, and you have invented this theoretical case (which did *not* occur) to try and make your point. I don't deny that requiring 'abstract' has some value, but what I question is how much is that value? Since a reasonable developer uses tests (or uses the code in question himself) and will end up instantiating any concrete class during testing (or usage), I'd say the value is pretty close to zero (not zero, but very close).
But let's assume for a moment that it's standard practice to avoid unit testing. The error that occurs is not a sneaky silent one, it is a loud compiler error. The only risk is that the user of your library finds it before you do, because you didn't test, but it still doesn't compile. Any time an error occurs at compile time, it is a win, since the user didn't accidentally use something incorrectly. So here's the solution -- use tests. In my opinion, breaking any existing code to add this requirement is unacceptable.
If the base class changes in any way, your derived class may not compile. It may break in subtle ways that *do* compile. If you are going to insist on not testing your code after the base class changes, well, then I guess you will have to get used to it failing. Just be thankful if you get a compiler error instead of a latent runtime error.
-Steve
