To emulate a session the way we usually do it in gargantext, our `unittests.framework` also
provides a session object to the test database via `GargTestRunner.testdb_session`
To work correctly, it needs to be read *inside the test setup.*
The GargTestRunner overrides default settings so that the test database is used in the way we usually do it in gargantext :
**Example**
```
from unittests.framework import GargTestRunner
from gargantext.util.db import session
class MyTestRecipes(TestCase):
def setUp(self):
# -------------------------------------
session = GargTestRunner.testdb_session
# -------------------------------------
new_project = Node(
typename = 'PROJECT',
name = "hello i'm a project",
)
session.add(new_project)
session.commit()
session.query(Nodes).all() # gives all the nodes of the testdb
```
...
...
@@ -123,12 +110,3 @@ class MyTestRecipes(TestCase):
```
*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 ?
- 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`
