Running unit tests will involve creating a **temporary test DB** !
+ it implies **CREATEDB permssions** for settings.DATABASES.user
(this has security consequences)
+ 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
------
```
./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
```
( `-v 2` is the verbosity level )
Tests
------
1.**tests_010_basic**
2.** tests ??? **
3.** tests ??? **
4.** tests ??? **
5.** tests ??? **
6.** tests ??? **
7.**tests_070_routes**
Checks the response types from the app url routes:
- "/"
- "/api/nodes"
- "/api/nodes/<ID>"
8.** tests users ??? **
9.**tests_090_toolchain**
Checks each data source parserbot (CSV, Pubmed, Zotero, Istex, etc.)
- correct parsing for a small sample
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.
It must be referenced in django's `settings.py` like this:
- but we have tables not in the migrations... so creating our full database model (with the `nodes_*` tables) implies either to hard-code their definitions or to:
1. do a `django.setup()` first so we can load the SQLAlchemy models (`import gargantext.models`)
2. from there use `util.db.Base` as the table definitions
- Table('nodes', Column('id', Integer()...)
- Table('ngrams' ...)
- etc.
3. Use those definitions to create the tables: `table_definition.create(engine)`
*(cf. db_migrate.py)*
#### But we see these two ordering strategies are contradictory!
**Explanation**: Doing the `django.setup()` to get the models will load the app modules before using the test database created by `DiscoverRunner.__init__()`
**Consequence**: `util.db.session` will use the native settings for the "real DB" instead of the "test DB".
#### So we need to "cheat" a little bit...
**Solution 1***(=> will be better in the long run when the tables stop changing)*
We could hard-code the list of tables and columns to create in the test DB. Then there would be no need to load the models to do the migration, so therefore no need to do a `django.setup()` before the `DiscoverRunner.__init__()`
**Solution 2***(=> used now)*
We do the `django.setup()` but we modify its `gargantext.settings.DATABASES` on-the-fly with this line:
This is a dirty hack because changing settings at runtime makes final values difficult to track, but this way, the setup part and the DiscoverRunner part will share the same DB name (`test_gargandb`)
### To inspect the testdb
Run tests with:
```
./manage.py test unittests/ --keepdb
```
And after the tests, connect to it as gargantua with `psql test_gargandb`
