in reply to Testing Template, or should I write a diff for TT templates?

I was actually thinking about this problem this morning (though with regard to HTML::Template, though it should be possible to generalize it to any template system).

The problem with keeping two sets of templates (production and debugging) is that a change in the variables sent means you have to update both templates. Ick.

Instead, the template module should take a 'debug' option. When activated, the template system will still open the template files and parse them (thus allowing things like HTML::Template's strict mode to work). However, instead of outputing the filled-in template, the system outputs a plaintext version containing the data structure that would otherwise be used to fill-in the template, and is thus easy to parse. Simply dumping with Data::Dumper would be OK (though that would make it harder to parse with anything except Perl). YAML would be a better choice.

----
I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
-- Schemer

: () { :|:& };:

Note: All code is untested, unless otherwise stated

Replies are listed 'Best First'.
Re: Re: Testing Template, or should I write a diff for TT templates?
by EvdB (Deacon) on Nov 14, 2003 at 18:11 UTC
    I thought of this as a solution and it is a good one, although I see a few problems:
    • It does not address the processing of data done in the template, such as total_price: [% item.quantity * item.unit_price FILTER format ( '%.2f' ) %].
    • It does not take into account editing of the template by someone not familiar with templates.
    • If the base templates are the responsibility of coder and the production ones the responsibility of the designer it will quickly point out where the problem is when there is one.
    • It creates an added complication in the code (albeit a tiny one) of creating the debug option in the template processing.
    That said I think that this would be an excellent additional check that I will add to my code - thank you. I too am a big YAML fan.

    I don't think that keeping the two sets of templates current would be that great a problem - although it will be annoying when the designer swaps the order of directives. This test is mainly geared towards preventing the designer from breaking the template, rather than proving the template.

    --tidiness is the memory loss of environmental mnemonics

[reply]
[d/l]
[select]
      Having two sets of templates is a bad idea from a testing standpoint. Testing is used to determine that the system behaves as you expect. It is more important that the production templates produce the right output. The test templates are something else that need to be maintained and they don't test that the production templates haven't been broken.

      There are two things that should be tested with templates. First, is that the program is passing the right data to the template. This is an interface question. This could be tested by writing a test template that just exercises the data. A better option is to have the tests directly examine the data.

      The second thing is that the templates produce the right output. Checking the output of the test template doesn't detect that the designer broke the production templates. A better test is to use pass test data to the production template. YAML would work very well for storing the test data. And then compare the output to a sample.

      Another possibility is to parse the production templates to produce the test templates. For example, removing all the HTML just leaves the directives. This could be compared to a sample whihc are basically the test templates you are talking about. This catches if the designer is not allowed to change the directives. If you are more concerned that the template directives work, then these could be run against the test data and the results compared to a sample.

[reply]

      It does not address the processing of data done in the template, such as total_price: [% item.quantity * item.unit_price FILTER format ( '%.2f' ) %].

      Since the template system is still reading the template file anyway, it could process such directives at that point and save the values for output later. That is, if your template system even allows programatically-generated fields in the template (HTML::Template doesn't in its main implementation).

      It does not take into account editing of the template by someone not familiar with templates.

      Shouldn't matter. By the time non-coders see the data, debug mode should have already been shut off.

      ----
      I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
      -- Schemer

      : () { :|:& };:

      Note: All code is untested, unless otherwise stated

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom