While not having done TDD before, I'm not new to that concept. The first thing I'm going do unit tests for is StrBuf (where i've already started); its a set of discrete functions all doing one specific transformation on a stringbuffer; The most complex one is the RFC822/iconv decoding one. I generaly expect this to be doable, but work.
The next thing on the list is our list implementation, which is going to be a little more difficult, but doable too, maybe a little more tricky. once it comes to webcit, its going to be more complicated; everything I did was done in a way to concentrate server I/O in one place per command which does de-serializing of the server data into the local structures. So here mock objects will be entering the game. The templating stuff is going to be more complicated; I think blackbox testing from the outside is more apropriate here. Several other criteria were applied; we always know the lengths of our string snippets, and can paste them together pretty quick. The other big one is to resolve what we're able to resolve at start time, so it doesn't affect our runtime performance. Yes, these afunction pointers are used all over the place; they give us a good modularity and resolve many of the interdependencies which were there before. Static constructors are done via a shellscript which gives us the hook api functions; dave introduced this design pattern. Close interaction with the profiler and the above design criteria give us a pretty fast thing, which i'm verry confident that its faster an it was before; we've got reports that we're pretty fast on 486's and became much faster with all the above changes. So, no, we're not leaving it to the compiler or some bytecode intepreter to do some vodoo magic beyound our control, we do it ourself.
