The following describes how the test routine tree view should look like. Note that it should be possible to have one generic class to handle all cases.

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
• TEST_B_01
  • test_routine_under_test
• MY_TESTS (manual test class)
  • test_1
  • test_2
  • test_3

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"

• TEST_ROOT_CLASS_01
  • test_routine_under_test
• TEST_ROOT_CLASS_02
  • test_routine_under_test
• A (manual test class with "covers" label)
  • test_1
  • test_2
• others
• MY_TESTS (manual test class with without "covers" label)
  • test_1
  • test_2

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
  • TEST_CLASS_2.test_routine
• tag2
  • TEST_CLASS_2.test_routine
• tag21
  • TEST_CLASS_4.test_routine
• name
  • TEST_CLASS_1.test_routine
  • TEST_CLASS_2.test_routine
  • TEST_CLASS_4.test_routine

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