How to test

How to test

Regression tests

In order to ensure that no loss or change of functionality occurs when extending the codebase, functional tests must be written. Each such test suite applies to a single part of code (usually a single module) and is written according to an RFC/XEP. The main RFC here would be XMPP Core.

Writing the tests

The workflow of writing a test suite is as follows:

1. Pick the module to write the suite for. E.g. for mod_privacy, the test suite would be called privacy_SUITE. All the suites are located in $EJABBERD_GIT/test/suites.

2. While writing the test cases add them to $EJABBERD_GIT/test/run_common_test.erl. Leading comma allows for fast and easy selecting of a single suite/group/test to run, which speeds up development (no need to wait for all tests to pass, when writing a single one).

3. Write a test case according to the RFC/XEP and ensure the unmodified ejabberd functions correctly.

4. Refactor/extend the codebase.

5. Ensure no functional regressions occured or that the new code works as expected by the specification(s).

Running the tests

Changing directory to $EJABBERD_GIT/test and running:

$ make test_clean

will make the tests specified in $EJABBERD_GIT/test/run_common_test.erl run. The results are available in $EJABBERD_GIT/test/reports.

Load tests

What do we need to do?

• zabbix template for an ejabberd node
  • graphs
  • graphs comparing different nodes
• remote access to the lab
• don't forget: mnesia extra_db_nodes "['ejabberd@nodename']" in vm.args (doesn't work anymore during runtime, must be passed as arguemnt at startup)
• strip ejabberd.cfg of unimportant cruft (unused modules, conf examples, ...)
• hostnames! old script does its job good enough (/etc/init.d/ejabberd-setup)
• make tsung dump XML stanzas