Testing

Before attempting to integrate imip-agent with other system components, it can be useful to check whether the different programs function as expected by themselves. Should errors or faults occur, these would need to be remedied first before attempting to get the software working with the mail and Web system components.

How the Software Works

To see how the software operates, you can run one of the agent programs provided in the distribution. For example:

./imip_resource.py -S xxx/store -P xxx/static -p xxx/prefs -d \
  < tests/templates/event-request.txt

This uses one of the test files, sending it to the agent program for resource entities, producing output resembling the following:

Outgoing parts for paul.boddie@example.com...
From nobody Wed Oct 28 00:24:41 2015
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Type: text/calendar; charset="utf-8"; method="REPLY"
From: calendar@example.com
To: paul.boddie@example.com
Subject: Calendar system message

QkVHSU46VkNBTEVOREFSDQpNRVRIT0Q6UkVQTFkNClZFUlNJT046Mi4wDQpCRUdJTjpWRlJFRUJV
U1kNCk9SR0FOSVpFUjptYWlsdG86cGF1bC5ib2RkaWVAZXhhbXBsZS5jb20NCkFUVEVOREVFO1NF
TlQtQlk9Im1haWx0bzpjYWxlbmRhckBleGFtcGxlLmNvbSI6bWFpbHRvOnJlc291cmNlLXJvb20t
Y29uZnJvb20NCiBAZXhhbXBsZS5jb20NClVJRDpmYjFAZXhhbXBsZS5jb20NCkVORDpWRlJFRUJV
U1kNCkVORDpWQ0FMRU5EQVINCg==

The rather opaque encoding can be inspected using the tools/showmail.py program, and thus the result of the script can be seen by piping the output through that program as follows:

./imip_resource.py -S xxx/store/ -P xxx/static/ -p xxx/prefs/ -d \
  < tests/templates/event-request.txt \
  | tools/showmail.py

The result should resemble the following:

Outgoing parts for paul.boddie@example.com...
MIME-Version: 1.0
Content-Type: text/calendar; charset="utf-8"; method="REPLY"
From: calendar@example.com
To: paul.boddie@example.com
Subject: Calendar system message

BEGIN:VCALENDAR
METHOD:REPLY
VERSION:2.0
BEGIN:VEVENT
DTSTAMP:20151027T232738Z
UID:event1@example.com
ATTENDEE;PARTSTAT=ACCEPTED;SENT-BY="mailto:calendar@example.com":mailto:reso
 urce-room-confroom@example.com
SUMMARY:Meeting at 4pm
ORGANIZER:mailto:paul.boddie@example.com
DTSTART;TZID=Europe/Oslo:20141126T160000
DTEND;TZID=Europe/Oslo:20141126T170000
END:VEVENT
END:VCALENDAR

What has happened here is the presentation of a request to the resource program in the form of an e-mail message containing an iCalendar event employing a scheduling method. The program interprets the request, consults its own records, makes a decision about scheduling the event, and indicates the kind of response it would like to send back to the requester.

The Test Suite

A script called test_all.sh is provided that runs a test suite (found in the tests directory within the source code distribution), initialising new and separate data store instances for each test, running programs that are presented with message content, and testing for the desired effects of running those programs with such content.

./test_all.sh

The test suite by default (or by indicating file as the data store type), records test information in subdirectories of /tmp.

To run all tests against a different data store, such as a database store instead of the file store, the STORE_TYPE environment variable can be specified as in the following example:

STORE_TYPE=postgresql ./test_all.sh

The test suite records postgresql tests in a specially-created database called imip_agent_test that the system user running the tests must be allowed to create and drop. This may require the granting of administrative rights within PostgreSQL for the system user concerned.

Individual tests may also be run directly from the topmost level of the source code distribution. For example:

tests/test_resource_invitation.sh

Should everything be functioning correctly, Success should be reported repeatedly as opposed to Failed. If the latter occurs, the output of the tests should be inspected: a number of files whose names end with .tmp will have been saved in the current directory, and these will contain the output from various commands from the last test script invocation; the err.tmp will contain tracebacks indicating serious error conditions, should any have occurred.

Testing in the Deployment Environment

Although the above testing may indicate that the software is functional, it does not demonstrate that the software has been successfully integrated into the deployment environment. One elementary test involves sending mail to an address that should be configured to handle incoming calendar messages.

A basic script is provided that replicates a subset of the functionality in the traditional mail command for sending messages. It is invoked by specifying the sender and recipients of a message and by passing the message itself to the script's standard input. For example:

tools/sendmail.py paul.boddie@example.com resource-room-confroom@example.com \
  < tests/templates/event-request.txt

Here, the sender (paul.boddie@example.com) and recipient (resource-room-confroom@example.com) must match the identities specified within the supplied file (tests/templates/event-request.txt), and for a specific deployment environment these identities will need to be changed. The following lines from the supplied file would be involved:

From: paul.boddie@example.com
To: resource-room-confroom@example.com
ORGANIZER:mailto:paul.boddie@example.com
ATTENDEE;ROLE=CHAIR:mailto:paul.boddie@example.com
ATTENDEE;RSVP=TRUE:mailto:resource-room-confroom@example.com

It makes most sense to choose a recipient acting as a resource so that an automated response may be generated with the sender receiving this response. However, other kinds of recipients may also be tested in this way.

The result of this invocation will become known via the following sources of information:

See the mail integration guide for more information about configuring and troubleshooting mail systems.