We use the new-feature/bug fix dichotomy to set a gross barrier on risky changes to a release branch, but the real issue is, it is likely to hinder the release? For example, Lars improved the error message for certain circumstances of ad_form, but within a day I had stumbled across a legit usage of ad_form which was now broken and we had to roll the change back. We have a diverse enough code base that it's really not ever 100% safe to change any programmatic behavior. Of course that's not a practical guideline for us. So, what I would like to see for changes of this type is:
somewhere between 1 and 10 new automated test cases, showing that the change works and doesn't break stuff. The test cases should include
- desired new usage
- vanilla old usage that doesn't use the new function
- example usage copied from current code base in core
- a different class of example, if possible, from core
- different classes of examples from standard packages or contrib
The test cases would then go into a file called
/packages/acs-templating/tcl/test/acs-templating-test.tcl
and a test case would look something like this (this code won't work as-is because I'm not sure how to use the adp processor internally, but it should be a starting point)
aa_register_case -cats {api} list__nested {
Test the list tag processor.
@author Joel Aufrecht
} {
set example1_adp {<list name="outer_list">
Outer Item Number: @outer_list:rownum@<br>
<list name="inner_list" value="@outer_list:item@">
item: @inner_list:item@<br>
</list>
<br>
</list>}
set desired1 {Outer Item Number: 1
item: 1
item: 2
item: 3
item: 4
Outer Item Number: 2
item: a
item: b
item: c
item: d}
set example_1_preparse [template::adp_compile -string $example1_adp]
# this will not work because adp_eval doesn't return anything
# and because this may mess up the current page processing
# this needs to do some stack manipulation ...
set example_1_text [template::adp_eval $example_1_preparse]
aa_true "Nested list parses successfully" [string equal $example1_text $desired1]
}
