it's a novel idea, and can be very useful, but I'm not
sure the "#ifdef(UNIT_TEST) virtual
#endif" is always a good idea.
I think testing a different code than your production
can bite you in the back sometimes.
for example, what if some code functional;ity or
performance changes when the function is made virtual?
if this is C++, you can end up changing the behvior of
the class (or make it have a VMT where it didn't
before), and even in safer languages like C#, I can
imagine cases where this would fail . Why not define
those virtual to start with, but mark them in some way
(e.g. comment which you WILL verify before shipping) to
be made non-virtual if that makes sense when the product
is done?
Yaniv: That's a good point: What if by the fact that
you're testing ,you've changed the behavior of the code?
That's why I think the first bullet point in this post
is the first one I'd choose: have known optimization
points, but don't optimize until you need to.
The last point lets a team with strict design rules
still have unit tests and thus minimize bug risks and
still keep playing by the "rules" of
the team. It's a settlement - not an overall solution,
and a lot of teams find it "good
enough".
Just a thought: as long as you're using macros, there's
nothing worse than #ifdefs all over the place. Just
#define a macro, say TESTVIRTUAL, then:
#ifdef UNIT_TEST
#define TESTVIRTUAL virtual
#endif
Then you can just
public:
TESTVIRTUAL void testpoint()...
Macros are awesome as long as they're using sparingly...