Skip to content

‐#4712 Section tests

Jump to bottom
David Wright edited this page Jul 7, 2023 · 1 revision

Anyone who feels this PR is scantily documented will welcome the explanation now added above of the cryptic test IDs in SelectOneResetTest.

Section tests

For each variant section of the test form, SelectOneResetTest performs ten distinct but logically related tests.

Each test is flagged in the code by an ID in a // comment and traced in the log.

Expected results of the tests are given in the asserts support sheet of the source form.

Encoding of test IDs

IDs are encoded as ((AA?)?BC)|(DE))(1|2|3|4)(e|h)? where

  • 1|2|3|4 is a logical test number
    • would come first if C syntax permitted (during development the IDs were enums)
  • (AA?)?BC tests a sequence of widgets in the (form)e(ntry) or h(ierarchy) views
    • ie in blocks A to C of each section
  • DE tests the behaviour of widgets in a field list
    • in blocks D and E

Test numbers

The purport of each test is defined by its number.

A quirk of the tests is that to simplify coding they're mostly executed in reverse order of how obvious they are, so here described in their natural order.

3 - All reset on state change

  • When state is changed, are all cascade members reset, including after an interpolated field (here show-ward)?
    • Confirms that a complete cascade will be reset following change in its (non-itemset) first member
    • The most obvious check

2 - Ward reset on city change

  • When city is changed, is ward as remaining cascade member reset, despite following show-ward?
    • Confirms that remaining cascade members will be reset following change in a preceding (itemset) member
    • Less obvious than 3 but just as critical

1 - Ward reset on unhide (relevance changed)

  • If show-ward is set to hide ward and then city changed, is ward reset when unhidden?
    • If a preceding member is changed while a question is hidden, then when the question is unhidden any existing answer will almost certainly be invalid
    • The subtlest of the tests but addresses what looks like a frequently-occurring issue

4 - Quit at new cascade

  • An important feature of the new algorithm

Block codes

Each block tests a different widget context, the principal distinction being between

  • A?BC - applied to widget sequences and their corresponding hierarchy views
  • DE - applied to widgets in field lists

(AA?)?BC assertions

  • Test widget sequences using conventional (form)e(ntry) assertions
  • Where practical, apply corresponding h(ierarchy) assertions.
  • Not practical for the hierarchy views of the top-level A groups.
  • AA test only in block A

DE assertions

  • Nothing is gained by testing both views as each displays all results.
  • DE(1|2)e test by navigating the expected states of widgets in the field list.
  • DE(3|4)h use the hierarchy view for ease of coding.
Clone this wiki locally