Test Classes and Methods

Test classes

Naming

OmnisTAP tests are stored in object classes that subclass omnistap.ogTAPSuper. Test classes are usually named with an underscore followed by the name of the class they test. For example, the test class for wLogin is _wLogin.

Location

Tests classes can either be in the same library as the class they test, or in a separate library. While they can be located in any folder, the convention is to create a [Production Code] Testing folder that would contain tests for the classes in [Production Code]. For example, tests for classes in a Email folder would be stored in Email Testing.

Using a separate library for test classes

By default, test classes are in the same library as production code. If you want your tests to be in a separate library, override the $useSeparateTestLibrary method in your Startup_Task and set it to return kTrue. This will cause the Jump to Counterpart command located below to create or load a test library for your production library and store tests there. This test library will located in the same directory as your production library and will be named [production library name]_tests.lbs.

If you want to manually add a testing library, follow these steps:

1. Create a library in the same directory as your production library named [production library name]_tests.lbs
2. Set the Startup_Task to subclass omnistap.kgTAPTask
3. Override $useSeparateTestLibrary and set it to return kTrue

You can then use the Jump to Counterpart command to open tests in your testing library and run those tests from the command line.

Note that for Jump to Counterpart to function properly, the Startup_Task for the test library should be instantiated (opened).

Creating

Using Jump to Counterpart

The easiest way to create a test class is to open a class or method editor for the class you wish to test, then choose Jump to Counterpart from the TAP menu. This command will open the test class for the active production class and, if the test class doesn't yet exist, automatically create it. You can then use Jump to Counterpart to switch between the production code and its test class.

Test classes created by Jump to Counterpart follow the naming and location conventions outlined above. They also create a standard mock of the production class in an overridden $setup() method. The mock will be defined as an instance variable thusly:

Class type being tested	Mock variable name	Type	Subtype
Table class	irMock	Row	The table class
Object class	iorMock	Object reference	The object class
All others	iirMock	Item reference	n/a

Assuming you use the naming convention defined below for test methods, Jump to Counterpart will alternate between the production method and its test method.

Manually

You can also manually create a test class. The class must sub-class omnistap.ogTAPSuper. Otherwise, you can treat it however you'd like.

Setup and teardown

omnistap.ogTAPSuper has $setup() and $teardown() methods. $setup() is called before each test method is run, and $teardown() is called after each test method runs. These are ideal locations to set up mocks or other environment settings for your test. Keep in mind these run for each test method in the test class, so keep your setup and teardown methods quick.

It is advised to call Do inherited in these methods.

Startup and shutdown for command-line runs

You can create a test class that subclasses omnistap.ogTAPStartupShutdown to provide code that runs at the beginning and end of a command-line test run. Override $startup() to run code at the start of the run, and $shutdown() to run code at the end of the run.

Test methods

Prefix

Test methods are denoted as either unit tests or integration tests by their prefix

Prefix	Type
$u_	Unit
$i_	Integration

OmnisTAP will enforce a timing restriction on unit tests. You can add additional assertion, such as ensuring unit tests don't run SQL in your database, but calling $cinst.$isUnitTest() in your $setup() and $teardown().

OmnisTAP ignores any other methods that do not use these prefixes.

Naming

After the standard prefix you can name the test method anything you'd like. However, the convention is to use the name of the method you're testing, minus any $ prefix. For example

Method being tested	Test method
$publicMethod	$u_publicMethod
$_protectedMethod	$u_protectedMethod
privateMethod	$u_privateMethod

NOTE: It's difficult to invoke private methods from a test since they are two different classes. One solution is to use the $insertForwardingMethod call to create a public wrapper on the private method. You can then call that wrapper to test the private method.

If you need to mock calls to the private method, consider adopting the $_protected() convention outlined in Suran's conventions for methods that should be invoked only on a class or its subclasses.