Changes between Version 1 and Version 2 of Using

Show
Ignore:
Timestamp:
10/17/11 15:04:07 (20 months ago)
Author:
mgalloy
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • Using

    v1 v2  
    77 
    88 
    9 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".  
     9Individual 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".  
    1010 
    11 For example, let's create some tests for the FINDGEN function. First, subclass MGutTestCase like below: 
     11For example, let's create some tests for the `FINDGEN` function. First, subclass `MGutTestCase` like below: 
    1212{{{ 
    1313  pro findgen_ut__define 
    … …  
    2828  end 
    2929}}} 
    30 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, use the following: 
     30Return `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, use the following: 
    3131{{{ 
    3232  IDL> mgunit, 'findgen_ut' 
    … …  
    3939A test case may have as many individual tests (methods with names starting with "test") as necessary.  
    4040 
    41 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: 
     41One 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: 
    4242{{{ 
    4343  function findgen_ut::test_error 
    … …  
    5050  end 
    5151}}} 
    52 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: 
     52As 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: 
    5353{{{ 
    5454  function findgen_ut::test_baderror 
    … …  
    7575Both test failures above are expected and present only to demonstrate features of mgunit. 
    7676 
     77A single test method of a test case can be run using a `.` to separate the test class name from the method name:: 
     78{{{ 
     79  IDL> mgunit, 'findgen_ut.test_basic' 
     80  "All tests" test suite starting (1 test suite/case, 1 test) 
     81     "findgen_ut" test case starting (1 test) 
     82        test_basic: passed (0.000078 seconds) 
     83     Results: 1 / 1 tests passed, 0 skipped 
     84  Results: 1 / 1 tests passed, 0 skipped 
     85}}} 
     86 
    7787 
    7888== Running multiple test cases == 
    7989 
    80 Another test case, indgen_ut, is provided as an example. It is analogous to findgen_ut for the INDGEN routine. 
     90Another test case, `indgen_ut`, is provided as an example. It is analogous to `findgen_ut` for the `INDGEN` routine. 
    8191 
    8292Multiple test cases can be executed by specifying them as an array: 
    … …  
    100110  Results: 4 / 10 tests passed 
    101111}}} 
    102 Alternatively, test cases may be grouped into test suites. Test suites are  just collections of test cases. To make a suite, subclass MGutTestSuite and use the add method in the the subclass' init method to add test classes. For example, to make a suite containing the indgen_ut and findgen_ut test cases: 
     112Alternatively, test cases may be grouped into test suites. Test suites are just collections of test cases. To make a suite, subclass `MGutTestSuite` and use the add method in the the subclass' init method to add test classes. For example, to make a suite containing the `indgen_ut` and `findgen_ut` test cases: 
    103113{{{ 
    104114  function indgen_uts::init, _extra=e 
    … …  
    119129  end 
    120130}}} 
    121 The commented out line will 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". 
     131The commented out line will 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". 
    122132 
    123133mgunit will also accept a mixed array of test suites and test cases, as in: 
    … …  
    130140== Fixtures == 
    131141 
    132 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. 
     142The `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. 
    133143 
    134144Pointer and object memory leaks can be tested for using fixtures by comparing the number of current pointers and objects during setup and teardown. 
    … …  
    137147== Other output == 
    138148 
    139 Results can be sent to a log file with the FILENAME keyword: 
     149Results can be sent to a log file with the `FILENAME` keyword: 
    140150{{{ 
    141151  IDL> mgunit, 'indgen_uts', filename='test-results.log' 
    … …  
    143153This will send the normal output to the results.log file. 
    144154 
    145 HTML output can also be created with the boolean HTML keyword to the MGUNIT routine. Generally, the FILENAME keyword is used in conjunction with this option: 
     155HTML output can also be created with the boolean `HTML` keyword to the `MGUNIT` routine. Generally, the `FILENAME` keyword is used in conjunction with this option: 
    146156{{{ 
    147157  IDL> mgunit, 'indgen_uts', filename='test-results.html', /html 
    148158}}} 
    149159 
     160 
    150161== Miscellaneous == 
    151162 
    152 Templates for the IDL Workbench are provided to make test/suite creation even faster. To use them, first navigate to the Workbench preferences. There should be a Templates section under the IDL heading. Click the "Import" button on the right and navigate to the "test-templates.xml" file in the mgunit source. Two new templates, "Test case" and "Test suite", should now be available. Typing "testcase" into a new file and then selecting Edit > Content Assist from the menus will create a test case which can be filled out like a form. Suites can be created the same way by typing "testsuite". 
     163Templates for the IDL Workbench are provided to make test/suite creation even faster. To use them, first navigate to the Workbench preferences. There should be a Templates section under the IDL heading. Click the "Import" button on the right and navigate to the "test-templates.xml" file in the mgunit source. Two new templates, "Test case" and "Test suite", should now be available. Typing "testcase" into a new file and then selecting *Edit > Content Assist* from the menus will create a test case which can be filled out like a form. Suites can be created the same way by typing "testsuite". 
    153164 
    154165 
    … …  
    157168It can be useful to create a subclass of MGutTestCase for a project so that each test case in the project inherits from that class instead of directly from MGutTestCase. This case can do work common to all the tests i.e. find the location of test data, have common setup/teardown methods, etc. 
    158169 
    159 The NTESTS, NPASS, and NFAIL keywords to the MGUNIT routine output the appropriate values. These can be handy for automated scripts i.e. sending email if any test fails, etc. 
     170The `NTESTS`, `NPASS`, and `NFAIL` keywords to the `MGUNIT` routine output the appropriate values. These can be handy for automated scripts i.e. sending email if any test fails, etc. 
    160171