in reply to Yet another meditation on testing
All tests revolve about the same thing: you have a piece of functionality (often a subroutine, but it could also be an operator or a program). You give whatever you are testing some known input, and you check whether the output is what you expect it is. If there's a difference, the test fails. As for a templating system, you can do several things. You could consider the template to be part of the product to test, which means you need to modify the tests if you change the template. Or you consider the templates to be input. Which means you probably have to multiply the number of tests with a factor X, and your tests have to be very generic. Or you could have two sets of test: one for the template you are using (meaning you need to change those tests if the template changes) and another set of tests for the functionality, using several different templates as input. I'd go for the last option - it's more work, but it covers things best.
I'm just confused, I guess what I'm really looking for is "real world" examples of tests for complex things, things you can just test by calling a function and comparing it's output to a constant.Don't get the impression that writing tests for complex things is easy. It might in some cases, but it often isn't. For some projects, I spend more than 80% of the time on writing the test cases.