Difference between revisions of "CddTreeViewSpec"
 
(9 intermediate revisions by the same user not shown)
Line 1: Line 1:
 +
[[Category:CDD]]
 +
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.
 
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.
  
Line 4: Line 7:
  
 
   
 
   
−
= Use case 1: Group by test class and routine name =
+
== 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.
 
We need an implicit tag for this that labels each routine with the class name it located in and the routine name.
Line 22: Line 25:
 
** test_3 ''(name.MY_TESTS.test_3)''
 
** test_3 ''(name.MY_TESTS.test_3)''
  
−
= Use case 2: Group by routine under test =
+
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".
 
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".
Line 37: Line 42:
 
** a2 ''(covers.A.a2)''
 
** a2 ''(covers.A.a2)''
 
* others
 
* others
−
* MY_TESTS
+
** MY_TESTS.test_1 (''no covers tag'', displayed using "name" tag)
−
** test_1 (''no covers tag'')
+
** MY_TESTS.test_2 (''no covers tag'', displayed using "name" tag)
−
** test_2 (''no covers tag'')
+
  
−
= Use case 3: Group by any 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.
 
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.
  
Line 63: Line 67:
  
 
Note that there is no "others". This is because of implicit tags. Every routine has at least one tag.
 
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.

Latest revision as of 04:56, 10 January 2008

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.

Retrieved from "https://dev.eiffel.com/index.php?title=CddTreeViewSpec&oldid=10258"