pennmush/test
Shawn Wagner f0d0cc0a59
Test fixes (#1413)
* Remove use of smartmatch operator

* Install colors.json into testgame directory tree
2024-02-25 12:05:47 -08:00
..
alltests.sh.in Hardcode Tests (#1243) 2018-09-16 15:10:11 -07:00
fuzz_flags.py Simple python script to fuzz the flags code in PennMUSH. 2013-07-23 19:44:07 +00:00
MUSHConnection.pm Some improvements to the test harness code. 2016-02-13 02:08:45 -08:00
PennMUSH.pm Test fixes (#1413) 2024-02-25 12:05:47 -08:00
README.md Hardcode Tests (#1243) 2018-09-16 15:10:11 -07:00
runtest.pl Add '.' back into @INC for the test harness script. 2017-07-30 11:40:34 -07:00
testalias.t Hardcode Tests (#1243) 2018-09-16 15:10:11 -07:00
testatree.t Make lattrp() behave like 1.8.6 again. Fixes #1233 2018-09-20 21:11:46 -07:00
testdecompose.t Hardcode Tests (#1243) 2018-09-16 15:10:11 -07:00
testdigest.t Hardcode Tests (#1243) 2018-09-16 15:10:11 -07:00
testdistxd.t Hardcode Tests (#1243) 2018-09-16 15:10:11 -07:00
testfirstof.t Hardcode Tests (#1243) 2018-09-16 15:10:11 -07:00
testflags.t Hardcode Tests (#1243) 2018-09-16 15:10:11 -07:00
testgrep.t Hardcode Tests (#1243) 2018-09-16 15:10:11 -07:00
TestHarness.pm Fix a warning in running softcode tests. Oops. 2018-09-16 15:21:19 -07:00
testhastype.t Hardcode Tests (#1243) 2018-09-16 15:10:11 -07:00
testinsert.t Hardcode Tests (#1243) 2018-09-16 15:10:11 -07:00
testjson.t Fix recursive calls to json_map(). Closes #1252 (#1253) 2018-10-03 16:07:33 -07:00
testjust.t Hardcode Tests (#1243) 2018-09-16 15:10:11 -07:00
testletq.t Hardcode Tests (#1243) 2018-09-16 15:10:11 -07:00
testlnum.t Hardcode Tests (#1243) 2018-09-16 15:10:11 -07:00
testmath.t Make the math test functions not depend on function aliases. 2018-11-11 20:55:04 -08:00
testnull.t Hardcode Tests (#1243) 2018-09-16 15:10:11 -07:00
testpage.t Hardcode Tests (#1243) 2018-09-16 15:10:11 -07:00
testrand.t Hardcode Tests (#1243) 2018-09-16 15:10:11 -07:00
testreswitch.t Hardcode Tests (#1243) 2018-09-16 15:10:11 -07:00
testsetfuns.t Hardcode Tests (#1243) 2018-09-16 15:10:11 -07:00
testsidefx.t Hardcode Tests (#1243) 2018-09-16 15:10:11 -07:00
testsort.t Hardcode Tests (#1243) 2018-09-16 15:10:11 -07:00
testsoundex.t Hardcode Tests (#1243) 2018-09-16 15:10:11 -07:00
teststringsecs.t Hardcode Tests (#1243) 2018-09-16 15:10:11 -07:00
teststrreplace.t Hardcode Tests (#1243) 2018-09-16 15:10:11 -07:00
testtime.t Hardcode Tests (#1243) 2018-09-16 15:10:11 -07:00
testtr.t Hardcode Tests (#1243) 2018-09-16 15:10:11 -07:00
testtrim.t Hardcode Tests (#1243) 2018-09-16 15:10:11 -07:00

Regression tests for Penn functions and commands.

Penn has two different test suites -- one for hardcode, one for softcode. This document describes how to run them and write tests for them.

Hardcode Tests

These are run at startup, after configuration files are read and the database is loaded, but before the game starts accepting connections. It's intended for things that can't easily be tested in softcode and things softcode tests themselves depend on working right.

Running tests

The --tests option to netmush runs the tests and logs the results to log/trace.log. The MUSH continues to finish starting up and running normally unless a test case fails, in which case it ends with exit code 1.

The --only-tests option also runs the test cases, but then exits instead of continuing to start up. An exit code of 0 means all tests passed, 1 means there were failures.

Writing tests

All source files that define tests need to #include "tests.h".

A test group is defined with the TEST_GROUP() macro like so:

TEST_GROUP(some_name) {
    // test cases
}

Each test group can have one or more tests. Tests for the same hardcode function should all go in a single test group. The tests look like:

TEST("name", test expression);

test expression should evaluate to a true value to indicate success, and 0 or false for failure. Failures get logged.

If a test group should only be called after another test group has successfully run, add a comment like:

// TEST some_name REQUIRES other_test1 other_test2

Softcode Tests

Running tests

From the test subdirectory:

$ perl runtest.pl [--valgrind] testFOO.t ...

or

$ ./alltests.sh [--valgrind]

Note: The the hardcode tests are automatically run as well.

Writing tests

The test*.t files in the test subdirectory define softcode test cases.

The --valgrind option runs the test game under valgrind to help detect memory issues.

Their format:

login mortal
expect N failures!
run tests:
test cases

All the lines above the 'run tests:' one are optional.

The test cases are perl code:

The test() function has four arguments -- the name of the test, the player to run it as (Either $god or $mortal, a softcode command, and a regular expression that should match the expected result (Or an array ref of REs).

The player objects have a command() method that runs its argument in the game without counting as a test: $mortal->command("think not a test");

Some hints: $god is always available as a test connection. If 'login mortal' was given, $mortal is too. See existing tests for examples of how to write new ones.