Testing Tool (Specification) - Revision history

Larryl: /* Manage and run test suite */

2009-12-31T04:06:39Z

‎Manage and run test suite

2009-12-31T03:36:00Z

‎Manage and run test suite

2009-12-31T03:27:13Z

‎Examples

2009-12-31T03:25:04Z

‎Extract tests from a running application

2009-12-31T03:24:31Z

‎Extract tests from a running application

2009-03-22T15:14:19Z

‎Compatibility with Getest =

2009-03-22T15:14:05Z

‎Wish list

2009-03-20T17:18:20Z

‎tests with context

2008-12-01T23:04:42Z

Modified examples according to lates changes in testing library

2008-10-08T16:46:40Z

‎Wish list

@@ Line 158: / Line 158: @@
 </eiffel>
 Just to keep things structured if at some point you have Eweasel tests and unit tests in the same project.
 ==== Different views ====

← Older revision		Revision as of 03:36, 31 December 2009
Line 146:		Line 146:

	{{Note\|Tags are defined as strings, but in the view we sometimes want a tag to represent a class, or a feature. The way this is done right now is that the view basically knows if the tag starts with "covers/" it is followed by a class and feature name. Another approach would be to define such tags like this: "covers.{CLASS_NAME}.feature_name". This would allow user defined tags to have clickable nodes in the view. We could also introduces other special tags such like dates/times.}}		{{Note\|Tags are defined as strings, but in the view we sometimes want a tag to represent a class, or a feature. The way this is done right now is that the view basically knows if the tag starts with "covers/" it is followed by a class and feature name. Another approach would be to define such tags like this: "covers.{CLASS_NAME}.feature_name". This would allow user defined tags to have clickable nodes in the view. We could also introduces other special tags such like dates/times.}}
		+
		+	You can create your own tags. Such as for the Eweasel tagging, you might have following tags in your note clause
		+	<eiffel>
		+	test_somthing
		+	-- Test something
		+	note
		+	testing: "eweasel/pass, eweasel/tcf"
		+	do
		+	-- test something
		+	end
		+	</eiffel>
		+	Just to keep things structured if at some point you have Eweasel tests and unit tests in the same project.

	==== Different views ====		==== Different views ====

@@ Line 59: / Line 59: @@
      test_append
-         indexing
+         note
              testing: "covers/{STRING}.append, platform/os/winxp"
          require
@@ Line 69: / Line 69: @@
      test_boolean
-         indexing
+         note
              testing: "covers/{STRING}.is_boolean, covers/{STRING}.to_boolean"
          require
@@ Line 99: / Line 99: @@
      test_version
-         indexing
+         note
              testing: "platform/os/linux/x86"
          do

@@ Line 195: / Line 195: @@
      test_append_integer
              -- Call `routine_under_test' with input provided by `context'.
-         indexing
+         note
              testing: "covers/{STRING}.append_integer"
          do

@@ Line 196: / Line 196: @@
              -- Call `routine_under_test' with input provided by `context'.
          indexing
-             tag: "covers/{STRING}.append_integer"
+             testing: "covers/{STRING}.append_integer"
          do
              run_extracted_test (agent {STRING}.append_integer, ["#1", 100])

@@ Line 244: / Line 244: @@
 It would be nice if the testing tool could generate a jUnit compatible output which can then be processed by other tools like a continuous build system. Of course this makes it necessary for the testing tool to be available from the command line.
-== Compatibility with Getest ===
+=== Compatibility with Getest ===
 Since Gobo test has been available long before Eiffel test, it would be nice if the testing tool also supported GOBO test cases. This is probably really easy to do since the difference are minimal. Basically only that gobo test cases require a creation procedure. It would also be a good start if EiffelTest would still recognize test cases when they list a creation procedure(s) as long as default_create is listed.

@@ Line 243: / Line 243: @@
 === jUnit compatible output format ===
 It would be nice if the testing tool could generate a jUnit compatible output which can then be processed by other tools like a continuous build system. Of course this makes it necessary for the testing tool to be available from the command line.
 == See also ==

@@ Line 240: / Line 240: @@
 I agree, it is not anymore automatic testing, since you need to make sure the execution goes by this "test point",
 but this would be useful to launch specific test with a valid context.
 == See also ==

← Older revision		Revision as of 16:46, 8 October 2008
Line 237:		Line 237:
	If you have any suggestions or ideas which would improve the testing tool, please add them to this section.		If you have any suggestions or ideas which would improve the testing tool, please add them to this section.

		+	=== tests with context ===
		+	it would be nice to have contextual test cases.
		+	For instance you would create a test class
		+	and you create an associated "test point" (kind of breakpoint, or like aspect programming)
		+	and then, when you run the execution in "testing mode" (under the debugger, or testing tool)
		+	whenever you reach this "test point", it would trigger the associated test case.
		+	I agree, it is not anymore automatic testing, since you need to make sure the execution goes by this "test point",
		+	but this would be useful to launch specific test with a valid context.

	== See also ==		== See also ==