|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
mjia commented 7 years ago | ||
dcallagh commented 7 years ago If you take this out it fails. That's because the db instance (which is a single shared global) is not hooked up to the app instance, which we only just created in this function. | ||
mjia commented 7 years ago It works fine in my evn. The global is hooked already in the create_app function. See line 47 at waiverdb/app.py | ||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
mjia commented 7 years ago My idea of using session is that each test will be running in their own fresh db. In this way, I do not need to worry about what other tests have put into the db. | ||
dcallagh commented 7 years ago Ahh but I don't think that actually works, does it? It is init'ing and dropping the db here in this fixture but it is session scoped. So you still get the same db for the entire test run. | ||
mjia commented 7 years ago Each test is wrapped in a transaction so it will not insert any data into the db since the transaction is rolled back on test teardown. | ||
dcallagh commented 7 years ago How does that work when the request handler does db.session.commit() though? | ||
dcallagh commented 7 years ago Also will this break down if a particular test doesn't explicitly request the | ||
mjia commented 7 years ago If the session fixture is not used, it may break down as it could insert some bad data. We could set autouse=True or just need to keep in mind for using it, :-) | ||
|
||
|
||
|
||
|
||
|
||
mjia commented 7 years ago This is just for keeping the sqlite db file as small as possible. If we have set up a Jenkins job to run the tests, it will generate a lot of temporary files on the server. It might cause problems. For debugging purpose, people can just hack the code to do it. | ||
dcallagh commented 7 years ago The pytest tempdir fixture already takes care of rotating the directories so they don't grow infinitely, while still keeping recent ones to be inspected by hand if necessary. That was why I suggested to use it :-) | ||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
We don't need to manage the session stuff manually, Flask-SQLAlchemy
already handles that if we hook it up correctly:
See: http://flask-sqlalchemy.pocoo.org/2.1/contexts/
We also don't need to drop all tables (it's already in a temp directory)
and leaving the data behind can help when investigating failing tests.
No need to do this. The db is already initialized when the app is created.