====== Testing Framework ======

===== Overview =====

**Launchpad URL:** [[https://blueprints.launchpad.net/sapidlib/+spec/testing-framework|https://blueprints.launchpad.net/sapidlib/+spec/testing-framework]]

**Description:** A framework/system that will run tests to help detect bugs and regressions within the mudlib.

**Components affected:** Master object

**Contributors:** CodySomerville

===== Release Notes =====

A testing framework has been developed that will result in fast and easy identification of regressions and bugs by allowing developers to write tests for their code.

===== Rationale =====

To help facilitate rapid development, a testing framework/system will be developed to help reduce overhead of testing new changes. 

===== Use Cases =====

  * Tricky develops tests for the I3 system and each of its modules to ensure that changes he makes in one area do not result in regressions/bugs elsewhere.
  * Cody made changes to how the rank daemon works without realizing that his change would break a component in the intermud channel module. That evening when the tests are automatically run, one of Tricky's tests detects the issue.

===== Design =====

Individual tests will be held in /obj/tests originally. 

The test daemon will:

  - load each test object
  - Call each function within the object that starts with "test_". Calling prepare_test() and cleanup_test() before and after the test respectively.
  - If a test fails, the test_{*} function will use the "throw" efun to send both control and a message back to the catch statement.

The test daemon will be designed to allow for different reporting methods (ie. text, html, etc.)

===== Implementation =====

The test daemon can be called manually but the master object will be modified to accept a flag that will run the test and then quit.
Furthermore, the test daemon will be scheduled to run periodically utilizing a call out (ie. every XX hours).



===== Discussion =====

== Why use throw instead of the error efun? ==

The throw efun is not logged like a normal error (which is what we want).

== Asynchronous testing of sockets. ==

When testing code that involves sockets (resolve(), FTP, I3, etc) the developer has to be aware of a delay for the response. Also the response will **not** come back to them in the test_* function that the message was sent out in.

At this moment in time I can not see a way of verifying the response.

 --- //[[harrison.rt@gmail.com|Richard Harrison]] 2008/01/17 20:02//

== Reporting methods ==

We could always output the data in XML format. Then all the developer would have to do is run something like xml2text or xml2pdf or whichever their favourite viewing media is.

Of course, a method to transfer the output to the user so they could run the conversion would have to be further discussed.

 --- //[[harrison.rt@gmail.com|Richard Harrison]] 2008/01/21 19:28//