Problem Code/Change/GetChangesMacro is the largest page in the application (741 lines) and builds an XWQL query from seven parameters. GetChangesMacroPageTest pins the versions filter and nothing else. With no assertion at any level:
- the audience lower-casing;
- the importance high|medium|low -> 2|1|0 rewriting (a regex rewrite over a comma-separated string);
- the two containsScreenshots clauses, which are hand-written as not (... <> '' or (... is not null and '' is null)).
Code/Change/ReleaseNotesChangesMacro passes exactly those values on all six of its getChanges calls. Two more gaps:
- The milestone/RC aggregation is untested at any level. ReleaseNotesChangesMacro derives the versions parameter from the page name (8.3M1 -> 8.3-milestone-1, 8.3RC1 -> 8.3-rc-1, 8.3 -> 8.3,8.3-milestone%,8.3-rc%). A regression makes a final release note silently drop every milestone change.
- Three of the four displayers are never rendered by any test. DisplayChangesMacro defaults to grid, so the functional tests only ever exercise Grid, although displayer="<name>" is documented as macro API. Simple, List and Flow would ship a broken include or a Velocity error unnoticed.
Why PageTests Per the XWiki testing strategy, variations of a use case belong in the cheapest test that can express them, and a PageTest is the level for a wiki page. All of the above are query-string or rendering assertions that GetChangesMacroPageTest already demonstrates the shape for. The functional-test-per-feature requirement is already satisfied by the existing ReleaseNotesIT tests. Note that ReleaseNotesIT test 1 exercises the filter paths against a release note with zero changes, so a silently empty result set passes today. |
