| 1 | ndgCommon testsuite - overview |
|---|
| 2 | -------------------------------- |
|---|
| 3 | |
|---|
| 4 | The test suite can be ran as a whole by running the 'noseTests.py' class as |
|---|
| 5 | a python app - otherwise, individual test classes can be ran as unittests. |
|---|
| 6 | |
|---|
| 7 | Setting up test environment: |
|---|
| 8 | ---------------------------- |
|---|
| 9 | |
|---|
| 10 | i) Some tests require an eXist DB config file, 'exist.config' to |
|---|
| 11 | be available - in the unittests/testdata directory. This should provide access |
|---|
| 12 | details to the required eXist database in the following format: |
|---|
| 13 | |
|---|
| 14 | hostname user password |
|---|
| 15 | |
|---|
| 16 | ii) Additionally, the testpostgresclient.py tests require a config file at: |
|---|
| 17 | |
|---|
| 18 | unittests/testdata/pg.config with the format: |
|---|
| 19 | |
|---|
| 20 | databaseName hostName userName password port |
|---|
| 21 | |
|---|
| 22 | - obviously, these will have to point to a running instance of postgres |
|---|
| 23 | |
|---|
| 24 | iii) The testconstants.py class defines constants to use for running the tests. |
|---|
| 25 | These don't need changing, typically, however, the EXIST_DB variable defines |
|---|
| 26 | which eXist host to use when running tests. Whilst the tests do clean up after |
|---|
| 27 | themselves, it's probably best not to run tests using a production environment DB! |
|---|
| 28 | |
|---|
| 29 | iv) Additionally, some tests expect a browse/discovery stack to be running and |
|---|
| 30 | available for use. Typically this just means deploying a MILK server and running |
|---|
| 31 | this. The file at: |
|---|
| 32 | |
|---|
| 33 | unittests/testdata/ndgDiscovery.config |
|---|
| 34 | |
|---|
| 35 | should be adjusted so that the DEFAULT server value points to this server. |
|---|
| 36 | |
|---|
| 37 | Errors |
|---|
| 38 | ----------- |
|---|
| 39 | noseTests is not always very reliable and quite often produces errors from tests |
|---|
| 40 | which run ok by themselves. If, after a run has completed, errors are output, it |
|---|
| 41 | is worth rerunning the test classes in question again - directly as python unit |
|---|
| 42 | tests. This will normally fix problems. |
|---|
| 43 | |
|---|
| 44 | NB, the errors usually encountered are like: |
|---|
| 45 | |
|---|
| 46 | error: (10048, 'Address already in use') |
|---|
| 47 | |
|---|
| 48 | - these suggest that some tests are being ran concurrently, although it's difficult |
|---|
| 49 | to see exactly what is going on. There are some tests that involve invoking |
|---|
| 50 | asynchronous code and these may interfere, although these include sleep periods |
|---|
| 51 | so this shouldn't be a problem... |
|---|
| 52 | |
|---|
| 53 | |
|---|
| 54 | |
|---|
