#include <TestFileSource.h>
Inheritance diagram for TestFileSource:
Public Member Functions | |
TestFileSource (const std::string &id) | |
virtual int | getNumSources () |
Data sources are enumbered from 0 to n-1 for the purpose of testing. | |
virtual void | getSourceConfig (int source, Config &config) |
virtual ClientTest * | getClientB () |
The instance to use as second client. | |
virtual bool | isB64Enabled () |
Returning true enables tests which only work if the server is a Funambol server which supports the "b64" encoding of items on the transport level. | |
virtual int | sync (const int *activeSources, SyncMode syncMode, const CheckSyncReport &checkReport, long maxMsgSize, long maxObjSize, bool loSupport, const char *encoding=0) |
Execute a synchronization with the selected sync sources and the selected synchronization options. |
More than one TestFileSyncSource can be active at once and each of them may (but does not have to be) used for different kinds of data. The name of the source determines which data is stored in it: it must be something supported by the ClientTest class, because that is where the test data comes from.
At least the following kinds of data are currently supported by the ClientTest class (see ClientTest::getTestData() for more information):
Configuration is done by environment variables which indicate which part below the root node "client-test" of the the configuration tree to use; beyond that everything needed for synchronization is read from the configuration tree.
For example, on Linux running
CLIENT_TEST_SERVER=funambol CLIENT_TEST_SOURCES=vcard21,vcal10 ./client-test
expects the following configuration layout:
~/.sync4j/client-test/ funambol_1/spds/ syncml/config.text sources/ vcard21/config.txt vcal10/config.txt funambol_1/spds/ <same as for funambol_1>
If any of the configuration nodes does not exist yet, then it will be created, but further information may have to be added, in particular:
The CLIENT_TEST_SERVER also has another meaning: it is used as hint by the synccompare.pl script and causes it to automatically ignore known, acceptable data modifications caused by sending an item to a server and back again. Currently the script recognizes "funambol", "scheduleworld", "synthesis" and "egroupware" as special server names.
The two configurations are used to simulate synchronization between two different clients.
The file sources will store their items in sub directories of a "client-data" directory created in the current working directory.
Here is an example of using the CLIENT_TEST_LOG:
CLIENT_TEST_SERVER=funambol \ CLIENT_TEST_LOG=/opt/Funambol-3.0/ds-server/logs/funambol_ds.log \ CLIENT_TEST_SOURCES=vcard21 \ ./client-test
will create files with the suffix .client.A.log for synchronizations with the first client and .client.B.log for the second client. The base name of these files is unique, so the corresponding part of the server log is stored with the same base name and .server.log as suffix.
For the test of the MappingsTest see the MappingsTest.h file
virtual int TestFileSource::getNumSources | ( | ) | [inline, virtual] |
Data sources are enumbered from 0 to n-1 for the purpose of testing.
This call returns n.
Implements ClientTest.
virtual ClientTest* TestFileSource::getClientB | ( | ) | [inline, virtual] |
The instance to use as second client.
Returning NULL disables all checks which require a second client. The returned pointer must remain valid throughout the life time of the tests.
The second client must be configured to access the same server and have data sources which match the ones from the primary client.
Implements ClientTest.