This document describes the unit testing of the SCHEMESTATION Messaging System. The purpose of the unit testing is to ensure that the messaging system can send and receive messages as specified in Messaging System Specification.
The module is rather small and will be tested as whole. The messaging module can not be tested without the addressing module, because the messaging queues reside in the address table. Therefore, the addressing system has to be tested before the messaging system.
In the module testing, the following aspects will be considered:
The module tests consist of calling each module with suitable arguments and verifying the result. A test program will be written that calls the functions as specified below.
The mess_callback and mess_sendheap functions are called with legal message and address as arguments. Then, using the addressing system's addr_dumpaddrssystem function, the address table is dumped on to the screen. The purpose is to manually verify that the messages have been placed in the right queues in right order.
The mess_callback and mess_sendheap are also called with randomly generated illegal arguments. The purpose is to ensure, that any illegal (or wrongly addressed) packet is silently ignored, and no error conditions arise from this.
The messaging system is supposed to transmit the messages to the agents in the scheduler's queue. Because the virtual machine and the scheduler are not involved in this testing a dummy function is provided that just dumps the messages on the screen.
The mess_unblockmessages-function is tested in similar manner; few agents are stored in the addressing system, and their blocking state is set to blocking or not blocking using the function. The result is verified with addr_dumpaddrssystem function.
The mess_writemessage and mess_readmessage-functions are tested by supplying a file handle to them and first writing some messages to disk and then reading them back. The test is considered succesful, if the the read message is consistent with the original.
The messaging system will be tested throughoutly as side effect of integration testing. We can expect that at least the following aspects will be tested this way:
The networking and messaging system were tested together. This was done after the addressing system tests as the testing demanded a functional addresing system.
As the plan for addressing system testing [SCHEMESTATION Networking Testing Plan] dictates, the test arrangement consisted of two stub SCHEMESTATION domains that were set to send messages to each other. More extensive testing with multiple domains took place in the integration tests.
The testing scheme included a 1-3 call test for each function, and a stress test, whose purpose was to unveil the memory leaks and defects in performance. We hoped also, that stress testing could reveal problems concering the non-blocking semantics of the networking system.
All of the test concerning the semantics of the functions were succesfully passed.
Numerous bugs were found, most of them have already been fixed.
| subject | status | result | comments |
| Do the functions implement the semantics defined in the spec? | done | passed | - |
| Do the functions survive calls with illegal arguments? | partly done | - | - |
| name | status | result | comments |
| mess_callback | done | success | |
| mess_init | done | success | |
| mess_readmessage | done | success | |
| mess_register_extagent_callback | done | success | |
| mess_register_special_agent | done | success | |
| mess_sendheap | done | success | |
| mess_unblockmessages | done | success | |
| mess_writemessage | done | success |