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...