Unit Testing

Executing Unit Tests

1. change directory into your Github Website clone.
2. run tests of the REST API: perl t/rest.t
3. run tests of the WormBase Perl API: API_TESTS=1 perl t/api.t
4. run comparative GBrowse tests: perl --base http://your.url.org:1234/cgi-bin/gb2/gbrowse

Successful tests are preceded by an "ok". For example:

ok 1 - require 't/rest_tests/template.t';
    ok 1 - port open
    1..1
ok 2 - test_port_open

How to read the output: The first "ok 1" means that the first executed test require ... completed sucessfully. "ok 2" shows that the second test was also successful, where sub-tests (i.e., tests within the test_port_open Perl sub) are shown above as indented lines. The interval "1..1" denotes the tests were run within test_port_open.

Failed tests are preceded by a "not ok" and a short description is displayed that explains why the test failed (lines preceded by "#"). For example:

    not ok 1 - port open
    #   Failed test 'port open'
    #   at t/rest_tests/template.t line 53.
    #          got: undef
    #     expected: anything else
    1..1
    # Looks like you failed 1 test of 1.
not ok 2 - test_port_open

API Unit Testing Framework: How it works / Write your own

Unit tests are

• based on Test::More.
• run on a fully populated WormBase database backend.
• API tests: start (and stop) a Catalyst web server (random port between 28,000 and 31,999)

Unit test templates are available as

• t/rest_tests/template.t for writing REST API tests
• t/api_tests/template.t for writing WormBase Perl API tests

New unit tests should be using the following workflow:

1. create a copy of template.t within the same directory; choose a descriptive filename
2. make appropriate changes to the newly created file

Comparative Testing Framework: GBrowse

Comparative GBrowse tests are

• based on a reference image set (one image per species, per track, per example landmark)
• comparing a live gbrowse_img rendering to the respective reference image