Testing OpenSync?

Here are some information that may guide people that want to help testing OpenSync, and don't know where to start from.

Setting up OpenSync?

See SetupGuide for information on how to build/setup OpenSync.

What to test

Most of OpenSync code is covered by the so-called "unit tests", that test parts of the code automatically. But they can't replace real user tests completely.

There are some things that needs to be tested more than others, specially the parts that can't be test automatically because they require user interaction. Some examples are: plugin behaviour (mostly KDE and Evolution plugins), and things that affect/are affected by user interaction (e.g. user interface tools usage).

Variables

Some things that may be tested:

• All object types: addressbook, calendar, to-do, notes
• All operations: adding, removing, changing data
• Mapping between the various fields (check if the data

entered on an application is on the correct places on the other application)

• Conflict handling: combinations of different operations on the same

object on both sides (e.g. a contact changed on evolution, and deleted on KDE)

Checking most combinations you can of the above variables is a good thing. Example: check if adding, removing, and changing is working for all object types.

Test uncommon test cases

It is a good idea to test uncommon and/or unpredicted cases, to see if they can cause some problems on the application.

Uncommon cases that can be tested:

• Behaviour when the PIM application is not configured yet

(i.e. home directory just created or .{evolution*,kde} directories deleted)

• Behaviour when the configuration is changed by the user

(e.g. the user runs synchronization, then change the evolution plugin configuration to another calendar, and try to synchronize again)

• Related to the item above: test behaviour when the user changes filter settings, check if changes made while some filter was set, are being reported and propagated to the other members, after disabling the filter
• Other ideas you may have. We should really stress the application,

and any ideas when creating uncommon test cases are welcome. Use your criativity :)

Filters

Filters could be tested, too. But we need a UI that allow the user to test the filter infrastructure.

TODO: Any suggestion? Maybe the multisync interface, I didn't look if it allows the user configure filters, yet

Making good tests

If you want to be a good tester, the tests you make should be:

• Reproducible: if possible, document all necessary steps to reach any problems
• Documented: take note of all testes that were done, even the successful ones
• Reported: use the ticket system to report all issues