A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
I'm sure this is obvious to most of the posters here, but I just thought of it, so sharing can't hurt anyone.
I working primarily in C++ and I've been working on integrating unit tests into my development process. I use generic programming whenever possible.
I figure that generic programming lets me specify the interface to my function at a finer grain than inheritance relationships do. So for example, instead of a callback requiring an inheritance relationship from a specific class, any function of the correct signature will do.
The use of generic programming has led to a design for a component utilizing template member functions. The ramifications of this choice mean that this interface cannot be implemented by any other objects. This can be unit tested fine.
But any components with a dependence on this interface are really dependent on that object. Only the non-template functions can even be given mock implementations with a different linking.
The obvious way to unit test in this situation would be to specialize specific implementations of these members with mock code. But the bigger issue is that you cannot reconcile coding to interfaces with template member functions or even many template objects.
Wednesday, October 10, 2007
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz