This could possibly go into SoPW, but it is more of a musing so here goes:

The problem I wish to address is content generated by Template from templates. I can envisage a situation where the perl code and the underlying templates are created and tested. Then in the future a web designer comes alnog and makes changes to the templates. Then the designer wants to check that they have not changed the functionality of the template in any way, which is a good thing. However they do not know Template beyond the very basics and know nothing of perl.

For example, how could a designer check that their modifications to the following are OK:

*** insert the introduction here ***
[% FOREACH item = items %]
id: [% item.id %]
name: [% item.name %]
quantity: [% item.quantity %]
unit_price: [% item.unit_price FILTER format ( '%.2f' ) %]
total_price: [% item.quantity * item.unit_price FILTER format ( '%.2f'
+ ) %]
[% END %]
** insert thank you here ***
[download]

The template above could be easily processed and then tested against expected data (regression testing) to ensure that it works.

My proposed solution to this is that there should be two sets of templates: one is used to generate the content in production, the other is used to test that the production templates behave as expected. These two sets of templates would be identical in terms of their functionality.

During testing the two sets of templates are compared to see if they are functionally the same - hence the diff for templates. However it is not straight forward to write a script which strips out everything but the Template commands.

I have the following thoughts / questions:

• Is this the right way to go about it. There will still need to be testing of the finished scripts to check that forms etc work but this catches errors earlier.
• Are there any tools that do this - ie compare two templates to see if they are the same?
• TIMTOWTDI: is there another (better) way?

I hope that this little musing of mine increases the ways to test, which for Templates currently appears to be quite few.