Unit tests for cheetah templates

[bellrichm]

This will require rewriting the templates to be consistent on use of ‘dot’ notation and dictionaries. For example the following are equivalent
$getVar('Extras.pages.' + $page + '.' + $section + '.filename', None)
$Extras['pages'][$page][$section].get('filename', None)
Being consistent will be a good thing.

I am leaning toward the 2nd (dictionary) version. I think it is a bit more readable.

• data/index.js.tmpl

• data/internationalization.js.tmpl

• generators/body.inc

• generators/data.gen

• generators/pages.gen

• javascript/index.js.tmpl

• sections/alert_modal.inc

• sections/basic_about.inc

• sections/chart.inc

• sections/current.inc

• sections/current_modal.inc

• sections/debug.inc

• sections/forecast.inc

• sections/minmax.inc

• sections/radar.inc

• sections/thisdate.inc

• sections/zoomControl.inc

• index.html.tmpl

• jas.css.tmpl

• manifest.json.tmpl

• user.css.tmpl

[bellrichm]

user.css.tmpl - one if statement, no need to create a test
manifest.json.tmpl - one variable, no need to create a test
sections/alert_modal.inc - no cheetah, no need to create a test
sections/basic_about.inc - a few ‘station’ variables, no need to create a test
sections/forecast.inc - limited cheetah, no need to create a test
sections/debug.inc - no cheetah, no need to create a test
sectons/radar.inc - limited cheetah, no need to create a test
sections/zoomControl.inc - no cheetah, no need to create a test

[bellrichm]

Turns out that I could write tests without having to refactoring the templates. It would still be good to refactor for consistency. That will be done via a different issue.