CddTreeViewSpec

Note: The Spec below is outdated. In order to release in time we have settled for a more simplistic design.

The following describes how the test routine tree view should look like. Note that it should be possible to have one generic GUI class that we can use for all of the below use cases.

Example notation: The examples represent the tree view. The bullet points represent the structure. The text after the bullent points represents the tag name. The tag responsible for the grouping is given in italics.

Use case 1: Group by test class and routine name

We need an implicit tag for this that labels each routine with the class name it located in and the routine name. Note that the contens of this tag does not state what is tested (covers). Let's call the tag "name". A test routine TEST_ROOT_CLASS_01.test_routine_under_test would have the following tag: "name.TEST_ROOT_CLASS_01.test_routine_under_test".

Example:

grouping key: "name"

• TEST_A_01
  • test_routine_under_test (name.TEST_A_01.test_routine_under_test)
• TEST_B_01
  • test_routine_under_test (name.TEST_B_01.test_routine_under_test)
• MY_TESTS
  • test_1 (name.MY_TESTS.test_1)
  • test_2 (name.MY_TESTS.test_2)
  • test_3 (name.MY_TESTS.test_3)

Note that there is no "others". This is because of implicit tags. Every routine has at least one tag.

Use case 2: Group by routine under test

For this we need a tag "covers" that indicates what is being tested. Test routines not having the grouping key are grouped together under "others".

Example: grouper key: "covers"

• ROOT_CLASS
  • foo (covers.ROOT_CLASS.foo)
  • foo (covers.ROOT_CLASS.foo)
  • bar (covers.ROOT_CLASS.bar)
• A
  • a1 (covers.A.a1)
  • a2 (covers.A.a2)
• others
  • MY_TESTS.test_1 (no covers tag, displayed using "name" tag)
  • MY_TESTS.test_2 (no covers tag, displayed using "name" tag)

Use case 3: Group by any tag

No grouper is defined. View is similar to gmail. Every distinct tag is a root node. Test cases are children of a root node if they contain the tag. Note that test cases may apear under several root nodes, since they might have several tags.

grouper key: ""

• tag1
  • TEST_CLASS_1.test_routine (tag1)
  • TEST_CLASS_2.test_routine (tag1)
• tag2
  • TEST_CLASS_2.test_routine (tag2)
  • tag21
    • TEST_CLASS_4.test_routine (tag2.tag21)
• name
  • TEST_CLASS_1
    • test_routine (name.TEST_CLASS_1.test_routine)
  • TEST_CLASS_2
    • test_routine (name.TEST_CLASS_2.test_routine)

...

• covers

...

Note that there is no "others". This is because of implicit tags. Every routine has at least one tag.

Use case 4: Group by outcome

Tests should be grouped by their outcome ("pass", "fail", and "unresolved").

grouper key: "covers"

• pass
  • MY_TESTS
    • test1 (covers.pass)
    • test2 (covers.pass)
  • FOO
    • bar1 (covers.pass)
    • bar2 (covers.pass)
• fail
  • FOO
    • bar3 (covers.fail)

Note that there is not "unresolved" node because in this example there were no unresolved test cases.

Use case 5: Group by callstack

Tests that were extracted from the same failure should be grouped together.

grouper key: "failure"

• arg_not_void, 12.1.2007
  • f0
  • f1
  • f2
  • f3
• v_small_enough, 1.5.2007
  • g0
  • g1
  • g2
  • g3

Note that 'f0' etc and 'g0' etc are the names of the routines for which the test case was extracted.