@@ -9,13 +9,12 @@ Running unit tests will involve creating a **temporary test DB** !
+ for instance in gargantext you would need to run this in psql as postgres:
`# ALTER USER gargantua CREATEDB;`
A "principe de précaution" could be to allow gargantua the CREATEDB rights on the **dev** machines (to be able to run tests) and not give it on the **prod** machines (no testing but more protection just in case).
Usage
------
From the django container directory to runs all tests type:
```
./manage.py test unittests/ -v 2
./manage.py test unittests/ -v 2 # in django root container directory
# or for a single module
./manage.py test unittests.tests_010_basic -v 2
...
...
@@ -39,28 +38,34 @@ Tests
- "/api/nodes/<ID>"
Creating a test DB
------------------
Most of the tests will interact with a DB but we don't want to touch the real one so we provide a customized test_runner class in `unittests/framework.py`
GargTestRunner
---------------
Most of the tests will interact with a DB but we don't want to touch the real one so we provide a customized test_runner class in `unittests/framework.py` that creates a test database.
Our custom class needs to be referenced as the `TEST_RUNNER` environment variable in django's `settings.py` like this:
It must be referenced in django's `settings.py` like this:
*Si vous aimez les aventures de Peter Corser, lisez l'album précédent ["Doors"](https://gogs.iscpif.fr/leclaire/doors)* (Scénario M. Leclaire, Dessins R. Loth) (disponible dans toutes les bonnes librairies)
FIXME
-----
url client get will still give read access to original DB ?