10946
Comment:
|
11202
|
Deletions are marked like this. | Additions are marked like this. |
Line 22: | Line 22: |
1. All test functions inside that namespace are expected to start their names with the string `Test_` followed by digits. | 1. All test functions inside that namespace are expected to start their names with the string `Test_` followed by digits. '''Update''': since version 1.1 test functions can be grouped. For example, in order to group all functions testing a method `foo` the test functions are named `Test_foo_001` (or `Test_foo_01` or `Test_foo_00001`), `Test_foo_002`, `Test_foo_003` and so on. |
Line 197: | Line 197: |
2 10 #.Tester.RunTheseIn #.TestCases ⍝ Just test cases 10 and 11 | 2 10 #.Tester.RunTheseIn #.TestCases ⍝ Just test cases 2 and 10 |
Tester
Contents
Tester is part of the CategoryAplTree project.
Overview
The purpose of this class is to provide a framework for testing all the projects of the APLTree project. Only with such a framework is it possible to make changes to the test suite without too much hassle. You might find the framework flexible enough to suit your own needs when it comes to implementing tests.
Details
Terminology
Note that test cases causing a crash are considered "broken". Test cases that do not return the expected result are considered "failing".
Assumptions and preconditions
The #.Tester class assumes that all your tests are hosted by an ordinary namespace. All methods running test cases take a ref to that namespace as an argument.
All test functions inside that namespace are expected to start their names with the string Test_ followed by digits. Update: since version 1.1 test functions can be grouped. For example, in order to group all functions testing a method foo the test functions are named Test_foo_001 (or Test_foo_01 or Test_foo_00001), Test_foo_002, Test_foo_003 and so on.
- The first line after the header must carry a comment telling what is actually tested. Keep in mind that later you might be in need for finding out which test cases are testing a certain method!
- It is assumed that you have three different scenarios when you want to run test cases with a different behaviour:
Run with error trapping and return a log (vector of text vectors) reporting details. Run this before checking your code into a Code Management System like SubVersion. See Tester.Run for details.
Run without error trapping. Use this for investigating why test cases crash. See Tester.RunDebug for details.
Run "batch mode". It is assumed that those test cases that need a human being in front of the monitor are not executed when running in batch mode. See Tester.RunBatchTests for details. (Of course it is best not to rely on a human being but this cannot always be avoided)
- Every test function must accept a right argument which is a two-item vector of Booleans:
stopFlag (0=use error trapping)
batchFlag (0=does not run in batch mode)
- Every test function must return a scalar integer with one of:
0: the test case is okay.
1: the test case failed.
-1: means the test case did not execute itself because it is not designed to run in batch mode.
Work flow
No matter which of the three main methods (Run, RunBatchTests, RunDebug) you are going to call, the workflow is always the same:
INI file s
First of all the Run* method checks whether there is a file testcases_{computername}.ini. If this is the case that INI file is processed. Use this to specify important computer-dependent variables.
It then checks whether there is a file testcases.ini. If this is the case that INI file is processed, too. Use this to specify general stuff that does not depend on a certain computer/environment.
Note that if one or both INI files exist there will be a flat namespace {yourTestNamespace}.INI, meaning that sections in the INI file are ignored. An example: if your test functions are hosted by a namespace "foo" and your INI file specifies a variable hello as holding "world" then:
'world'≡#.foo.INI.hello 1
Initialisation
Now the Run* method checks whether there is a function "Initial" in the hosting namespace. If that is the case then the function is executed.
Note that the function must be either niladic or monadic and must not return a result. If the function is monadic then a Boolean is passed via the right argument telling the function that the test suite is going to run in batch mode if true.
Use this function to create stuff that's needed by all test cases, or tell the user something important - if the batch flag is false.
It might be a good idea to call a function tidying up in line 1, just in case a failing test case has left something behind; see below for details.
Finally: running the test cases
Now the test cases are executed one by one.
Tidying up
After the last test case was executed the Run* function checks whether there is a function "Cleanup" in the namespace hosting your test cases. If that's the case then this function is executed. Such a function must be a niladic, no-result returning function.
INI file again
Finally the namespace "INI" holding variables populated from your INI file(s) is deleted.
Best Pratices
- Try to keep your test cases simple and test just one thing at a time, if possible a method.
- Create everything you need and tidy up afterwards. Or more precisely, tidy up (left overs!), create, test, tidy up again.
- ....
Methods
Show the methods
Examples
Show the examples
Project Page
For bug reports, future enhancements and a full version history see Tester/ProjectPage
Version Information
Original author: |
|
Responsible: |
|
Email: |