Comment onby gods
|on Feb 11, 2000 at 00:06 UTC||Need Help??|
Here are a pair of techniques I helped devise a while back when unit testing UIs for web applications. If they work for you, you're welcome to them. If you have a better way, please post. I can alway use more testing tricks.
So you got the Unit Test religion, and you're building up a set unit tests as you develop a web-based application. Good for you. And you're using templates to separate as much content as you can from application logic. Good for you again. Now how to you write unit tests that you won't have to touch every time someone changes a template? And how do you test in the presense of some dynamic data (like file modification times) that you can't easily dummy up?
How We Approached the Problem
This worked great when the template expansion could be forced to be "statically dynamic". That is, when the "underlying" dynamic data could be supplied statically by the unit tests. But we kept having stuff like file modification timestamps that couldn't easily be faked without causing some intrusive changes to the code. (We were trying to avoid having special debugging logic interwoven through the codebase.) What to do?
Our first approach was to write some custom post-diff logic that would figure out what differences were safe to ignore. This was an ugly hack. In some cases it mean an extra page of Perl per unit test, to massage diff output before deciding whether a test had really failed, or whether it passed once some set of magic differences were ignored. Yuck.
Insight number two was to insert pairs of special HTML comment markers into our testing templates to denote where dynamic stuff would appear when a given template was expanded. Then, before diff'ing the results against the known-good reference output, we would wipe out the special comment tag pairs and everything in between each pair. The diff was then straightforward and authoritative. All of the kludgey "what do we ignore in the diff output for this test" logic went away. Very cool