Difference between revisions of "Testing Tool (Specification)"
(→Add unit/system level tests) |
(Cosmetics) |
||
Line 22: | Line 22: | ||
For each target in a configuration file you may define a testing folder in which test classes, but also other files needed for testing can be put there. | For each target in a configuration file you may define a testing folder in which test classes, but also other files needed for testing can be put there. | ||
− | + | {{Note| special testing folder is needed when automatically creating new test cases. Also system level tests rely on a location for files etc...}} | |
− | + | ||
==== Additional information ==== | ==== Additional information ==== |
Revision as of 07:30, 9 June 2008
Contents
Main functionalities
Add unit/system level tests
Semantically there is no difference between unit tests and system level tests. This way all tests can be written in Eiffel in a conforming way.
A test is a routine having the prefix test in a class inheriting from TEST_SET. In general features in classes specifically used for testing should be exported at most to {TESTING_CLASS}. This is to prevent testing code from remaining in a finalized system. If you write a helper class for your test routines, let it inherit from TESTING_CLASS (Note: TEST_SET already inherits from TESTING_CLASS). Additionally you should make leaf test sets frozen and make sure you never directly reference testing classes in your project code.
System level test specifics
Since system level testing often relies on external items like files, SYSTEM_LEVEL_TEST_SET provides a number of helper routines accessing them.
Config file
For each target in a configuration file you may define a testing folder in which test classes, but also other files needed for testing can be put there.
Note: special testing folder is needed when automatically creating new test cases. Also system level tests rely on a location for files etc...
Additional information
The indexing clause can be used to specify which classes and routines are tested by the test routine. Any specifications in the class indexing clause will apply to all tests in that class. Note testing_covers in the following examples.
Examples
Example unit tests test_append and test_boolean
frozen class TEST_STRING inherit TEST_SET redefine set_up end feature {NONE} -- Initialization set_up do create s.make (10) end feature {TESTING_CLASS} -- Access s: STRING feature {TESTING_CLASS} -- Test routines test_append indexing testing_covers: "{STRING}.append" require set_up: s /= Void and then s.is_empty do s.append ("12345") assert_string_equality ("append", s, "12345") end test_boolean indexing testing_covers: "{STRING}.is_boolean, {STRING}.to_boolean" require set_up: s /= Void and then s.is_empty do s.append ("True") assert_true ("boolean", s.is_boolean and then s.to_boolean) end end
Example system level test test_version (Note: SYSTEM_LEVEL_TEST_SET inherits from TEST_SET and provides basic functionality for executing external commands, including the system currently under development):
indexing testing_covers: "all" frozen class TEST_MY_APP inherit SYSTEM_LEVEL_TEST_SET feature {TESTING_CLASS} -- Test routines test_version do run_system_with_args ("--version") assert_string_equality ("version", last_output, "my_app version 0.1") end end
Manage and run test suite
This is what a screen shot of the above example could look like: