TestFileSource Class Reference
[Client Testing]

This code uses the ClientTest and TestFileSyncSource to test real synchronization against a server. More...

#include <TestFileSource.h>

Inheritance diagram for TestFileSource:
[legend]
Collaboration diagram for TestFileSource:
[legend]

List of all members.

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)
 Called to fill the given test source config with information about a sync source identified by its index.
virtual ClientTestgetClientB ()
 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.

Private Member Functions

SyncSourcecreateSource (int source, const char *trackingSuffix)

Static Private Member Functions

static SyncSourcecreateSource (ClientTest &client, int source, bool isSourceA)

Private Attributes

std::string clientID
 either "A" or "B" for first respectively second client
std::auto_ptr< TestFileSourceclientB
 only in "A": pointer to second client
std::vector< std::string > sources
 vector of enabled sync sources, identified by a name which SyncClient::getConfig() supports
std::auto_ptr< DMTClientConfigconfig
 configuration tree itself


Detailed Description

This code uses the ClientTest and TestFileSyncSource to test real synchronization against a server.

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


Member Function Documentation

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.

References clientB.

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.

References sources.


The documentation for this class was generated from the following files:

Generated on Tue Apr 6 13:00:43 2010 for Funambol Outlook Plug-in Library by  doxygen 1.5.7.1