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.
Abigail
In Section
Meditations