- Timestamp:
- 09/28/11 15:44:36 (8 months ago)
- Files:
-
- 1 modified
-
trunk/docs/using-mgunit.rst (modified) (6 diffs)
Legend:
- Unmodified
- Added
- Removed
-
trunk/docs/using-mgunit.rst
r112 r122 14 14 --------- 15 15 16 Individual tests are methods of a class that subclasses MGutTestCase. Each method returns 1 for success or 0(or throws an error) for failure. Each test method's name must start with "test".16 Individual tests are methods of a class that subclasses `MGutTestCase`. Each method returns `1` for success or `0` (or throws an error) for failure. Each test method's name must start with "test". 17 17 18 18 For example, let's create some tests for the `FINDGEN` function. First, subclass `MGutTestCase` like below:: … … 35 35 end 36 36 37 Return 1 for success. For failure, either return 0 or throw an error. Here the helper routine `ASSERT` will throw an error using the given message if its condition is not met. This will be reported as a failure along with the message. To run this test, usethe following::37 Return `1` for success. For failure, either return `0` or throw an error. Here the helper routine `ASSERT` will throw an error using the given message if its condition is not met. This will be reported as a failure along with the message. To run this test, do the following:: 38 38 39 39 IDL> mgunit, 'findgen_ut' … … 46 46 A test case may have as many individual tests (methods with names starting with "test") as necessary. 47 47 48 One tricky situation is that sometimes invalid input must be tested to make sure the routine fails. In these situations, throwing an error should indicate the success of the test, not a failure. In this case use the provided batch file error_is_passat the beginning of the routine, like::48 One tricky situation is that sometimes invalid input must be tested to make sure the routine fails. In these situations, throwing an error should indicate the success of the test, not a failure. In this case use the provided batch file `error_is_pass` at the beginning of the routine, like:: 49 49 50 50 function findgen_ut::test_error … … 57 57 end 58 58 59 As an example of showing a failing test, the example test case includes a test_fail_example method with an invalid assertion. Also provided is an example of using the error_is_fail batch file in the test_baderror method. Runtime errors will cause a test to fail, but IO errors normally will not. The test_baderror test uses @error_is_failto make an IO error cause the test to fail::59 As an example of showing a failing test, the example test case includes a test_fail_example method with an invalid assertion. Also provided is an example of using the `error_is_fail` batch file in the `test_baderror` method. Runtime errors will cause a test to fail, but IO errors normally will not. The `test_baderror` test uses `@error_is_fail` to make an IO error cause the test to fail:: 60 60 61 61 function findgen_ut::test_baderror … … 127 127 end 128 128 129 The commented out line w illspecifically add `indgen_ut` and `findgen_ut`, wherever their source code files may be located. Instead, the `ALL` keyword is used to add all test cases in the same directory as the test suite source code file. Test cases to be found in this manner must use the convention to name the class with an appended "_ut", as in "findgen_ut".129 The commented out line would specifically add `indgen_ut` and `findgen_ut`, wherever their source code files may be located. Instead, the `ALL` keyword is used to add all test cases in the same directory as the test suite source code file. Test cases to be found in this manner must use the convention to name the class with an appended "_ut", as in "findgen_ut". 130 130 131 131 mgunit will also accept a mixed array of test suites and test cases, as in:: … … 139 139 -------- 140 140 141 The setup and teardown methods of a test case class are executed before and after each individual test. By default, they are empty, but subclasses of `MGutTestCase` can override them to do any common setup/teardown tasks. Any data to be stored from the setup is normally saved as an instance variable of the test case class so that it can be accessed by the test and the teardownmethod.141 The `setup` and `teardown` methods of a test case class are executed before and after each individual test. By default, they are empty, but subclasses of `MGutTestCase` can override them to do any common setup/teardown tasks. Any data to be stored from the setup is normally saved as an instance variable of the test case class so that it can be accessed by the test and the `teardown` method. 142 142 143 143 Pointer and object memory leaks can be tested for using fixtures by comparing the number of current pointers and objects during setup and teardown. 144 145 146 Invalid tests 147 ------------- 148 149 Sometimes there are tests that are only valid to run in certain circumstances. The `ASSERT` routine can be used to stop a test from counting in the final tally of passes and failures, but using the `SKIP` keyword. For example, if you only want to run a test if running IDL 8.0 or later, put the following at the beginning of the test:: 150 151 assert, long(strmid(!version.release, 1, 1)) ge 8, $ 152 'IDL version too old: %s', !version.release, $ 153 /skip 144 154 145 155
