This document describes the unit testing of the SCHEMESTATION networking system. The purpose of the unit testing is to ensure, that the implemented networking system corresponds to the specified networking protocol [Networking Specification] and that messages can be passed between domains with reasonable performance.
Testing the overall functionality of the module is dicided in to following categories:
Each function is tested separately. For each function the following is tested:
The networking system will be flooded with maximum amount of packets that the system can produce, and with packets that contain illegal headers.
A separate testing program will be written to test all the networking operations. The testing involves having two test programs to act as minimal domains and communicate with each other via one test router. The two domains and the router are three instances of one executable, that acts as router, if a specific command line argument is supplied. The two client programs also get their own domain address, the address of the router and the address of the other client program as a command line argument.
The host address is set with net_sethostaddress(). The result is verified with gdb.
The networking system is initialized by calling net_initialize.
The net_becomerouter is called, if corresponding command line argument was supplied. This way, one of the testing executables can act as a router. Unless the command line attribute was supplied, net_userouter is called to initiate connection to the router.
A packet callback is supplied for the system using net_registerpacketcallback. The callback dump the gotten packet on to the screen.
The result of the hand shake initiated between the router and the client will be checked using gdb. Also, a perl script will be written to try to connect to the router with false protocol. The router may neither accept the connections nor stop serving the valid connections.
In the sending phase, another of client programs (those not instructed to become routers) basicly executes a thight loop sending packets to the other client program. The client program client program can be put in to this mode with eg. typing a suitable key combination. The other client sits in a loop too and dumps the received messages to stdout.
The result is verified by counting number of received messages and sent messages. The sending party can be instructed to dump the sent messages to stdout, too, so that the possible errors can be caught using diff(1).
Another of the client programs will be set to "malfunction" mode - it will flood the router with random packets. It will be checked that none of these packets cause denial of service neither for the malfunctional client nor the intact client. All invalid packets have to be ignored.
The described testing programs were written and executed in parallel.
The functions are tested to carry out their tasks when proper arguments are supplied. The invalid argument testing is not yet accomplished.
The ability to deal with malfunctional connection has been tested with the testing programs.
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 | - | - |
| Stress test - flood the network system with maximum amount of packets | done | passed | - |
| Does the system cleanly drop invalid connections | done | passed | - |
| name | status | result | comments |
| net_acceptconnection | done | success | |
| net_addresstoasc | done | success | |
| net_becomerouter | done | success | |
| net_closeconnection | done | success | |
| net_cmpraddr | done | success | |
| net_connectcallbk | done | success | |
| net_delete_packets | done | success | |
| net_deliverpacket | done | success | |
| net_destroypacket | done | success | |
| net_doclienthandshake | done | success | |
| net_doserverhandshake | done | success | |
| net_dropconnection | done | success | |
| net_eloop_callback | done | success | |
| net_findconnection | done | success | |
| net_get_info | done | success | |
| net_get_tcpip_addr | done | success | |
| net_getconnection | done | success | |
| net_gethostaddress | done | success | |
| net_getrecpaddr | done | success | |
| net_handlecontrol | done | success | |
| net_initialize | done | success | |
| net_makessppaddress | done | success | |
| net_newconnection | done | success | |
| net_open_connection | done | success | |
| net_openconnection | done | success | |
| net_packettoasc | done | success | |
| net_protoconnection | done | success | |
| net_recvpacket | done | success | |
| net_registerpacketcallback | done | success | |
| net_send | done | success | |
| net_sendpacket | done | success | |
| net_set_event_loop_reqs | done | success | |
| net_sethostaddress | done | success | |
| net_shutdown | done | success | |
| net_userouter | done | success |