CddTreeViewSpec - Revision history

Aleitner at 13:56, 10 January 2008

2008-01-10T13:56:10Z

2008-01-04T13:10:44Z

‎Use case 4: Group by outcome

2008-01-04T12:41:13Z

2007-12-30T00:23:23Z

‎Use case 4: Group by outcome

2007-12-30T00:22:57Z

‎Use case 4: Group by outcome

2007-12-30T00:22:37Z

‎Use case 3: Group by any tag

2007-12-28T19:09:31Z

‎Use case 2: Group by routine under test

2007-12-28T19:08:37Z

2007-12-28T19:08:13Z

2007-12-28T19:07:54Z

‎Use case 1: Group by test class and routine name

← Older revision		Revision as of 13:56, 10 January 2008
Line 1:		Line 1:
	[[Category:CDD]]		[[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.

← Older revision		Revision as of 13:10, 4 January 2008
Line 82:		Line 82:

	Note that there is not "unresolved" node because in this example there were no unresolved test cases.		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.

← Older revision		Revision as of 12:41, 4 January 2008
Line 1:		Line 1:
		+	[[Category:CDD]]
	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.

← Older revision		Revision as of 00:23, 30 December 2007
Line 79:		Line 79:
	** FOO		** FOO
	*** bar3 ''(covers.fail)''		*** bar3 ''(covers.fail)''
		+
		+	Note that there is not "unresolved" node because in this example there were no unresolved test cases.

← Older revision		Revision as of 00:22, 30 December 2007
Line 64:		Line 64:

	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)''
		+	* unresolved

@@ Line 39: / Line 39: @@
 ** a2 ''(covers.A.a2)''
 * 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 ==

@@ Line 21: / Line 21: @@
 ** test_2 ''(name.MY_TESTS.test_2)''
 ** test_3 ''(name.MY_TESTS.test_3)''
 == Use case 2: Group by routine under test ==

← Older revision		Revision as of 19:07, 28 December 2007
Line 4:		Line 4:


−	= 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.