A bit off-topic

Dave, in episode 7, you mention you should do unit testing when metaprogramming.
While I try to use unit-testing on most of my normal code, I find it’s harder to unit-test metaprogramming-code.
I always find myself testing the implementation too much instead of the results.
So my tests are bound too much to the code they test, which is a bad thing.

I would be really interested to see you work through episode 7 with unit-testing. Like you said, this breaks up the flow too much for the original screencast, but maybe you can do a separate one on that?
Or could you make your unit-tests (of the final example at least, maybe of some between-steps) available in the code or somewhere else?

This would greatly help me find a nice and safe workflow when metaprogramming.

Thanks,
Mathijs

Mathijs:

To be fair, I didn’t say I don’t do unit testing when metaprogramming. I just said I wasn’t doing it in the screencast—after all, it’s already over 50 minutes, and Mike Clark gave me a 30 minute target…

Remember that metaprogramming is orthogonal to your final code. When you write tests, you write tests for the metaprogramming implementation separately from the tests you write for your use of that metaprogramming. And, because they are unit tests, it’s OK to know about the implementation.

Dave