Persister Tester

The persister tester is a program that can be used after deploying the persister, to test the persister independently of the other modules.

It requires the aidr-persister and aidr-tagger-api module to be deployed.

Command line

The persister tester is run through the following command:

mvn test -Dtest=PersisterTesterTest PARAMETERS

These parameters are optional:

-Dconfig=FILE
-DnItems=NUMBER (default 1000)

The config is the name of the persister configuration (or of a centralized configuration) to read properties that the tester needs to know to perform the testing: the URL of the persister's API, the name of the REDIS queues from which the persister reads, the name of the directory in which the persister writes, the base URL from which the generated CSV files need to be downloaded.

The nItems is the number of items that should be written to the persister.

Execution

The persister test should generate a collection name as YYYYMMDDhhssmm-persister-test. It should also generate synthetic Twitter messages with random texts and random tweetids.

Phase A: test the collector persister.

1. Call the collectorPersister/start API, if it doesn't return OK, FAIL.
2. Write to REDIS nItems/2 items, if writing is not possible, FAIL.
3. Call the collectorPersister/status API, if it doesn't return OK, FAIL.
4. Write to REDIS nItems/2 items, if writing is not possible, FAIL.
5. Call the collectorPersister/stop API, if it doesn't return OK, FAIL.
6. Call the collectorPersister/status API, if it doesn't return that the collection is not running, FAIL.
7. Read the directory where the persister file should be located, if the directory does not exist, FAIL.
8. Count the number of items in the file, if it doesn't match nItems, FAIL.
9. If this point is reached, exit with success code.

Phase B: test the taggerPersister, doing the same operations as above but against the taggerPersister/ APIs.

Phase C: test a simple CSV generation routine.

1. After phase B is completed, call taggerPersister/genCSV, if it doesn't return OK, FAIL.
2. Download the corresponding CSV file, if it is not downloadable, FAIL.
3. Count the number of rows in this CSV file, if it doesn't match nItems, FAIL.
4. If this point is reached, exit with success code.

FAIL means printing a clear and informative message describing the condition and exiting with code 1 (non success).

On interrupt by the user, the persister tester should attempt to call the persister's collectorPersister/stop and taggerPersister/stop methods and exit with non-success code.