db_session needed?

A usage question / request for clarification in the docs, but does the test need to use the db_session fixture, or is there a way to shim all usages of the session throughout the code? That way I can make sure to rollback the transaction anywhere there is an exception.

[jeancochrane]

That’s one way to do it! Although then all of your tests will load the fixtures, whether or not they touch the database – since the transactional fixtures are function-scoped and require DB interaction, that might mean an unnecessary performance hit to your tests. So far I’ve always preferred listing the db_session dependency explicitly, although it can definitely feel overly verbose.

There had been some talk about introducing a simple mark like @pytest.mark.transactional that would load the shims in a test without explicitly requiring db_session. (In a test implementation I did a few months back, this basically meant that db_session would be automatically required as a dependency but not loaded into the body of the test – so functionally identical to listing it in the parameters.) We decided against it because it seemed to not add value and was just another thing to document. For your use-case, would that be a more appealing solution than using either usefixtures/autouse or requiring it explicitly?

[jeancochrane]

Thanks for the feedback @mbalaa-spring! Just added two new sections to the docs in https://github.com/jeancochrane/pytest-flask-sqlalchemy/commit/7e1e9e496f04cda635a8166abfc58fd821de2661, one to help clarify that a transactional fixture (like db_session) is required in a test signature order to enable transactions in that test, and one to suggest a solution for automatically enabling the fixture for all tests using pytest’s autouse fixture argument. For now I’m not planning on adding a feature to automatically enable transactions for all tests, mostly because the autouse workaround documented in https://github.com/jeancochrane/pytest-flask-sqlalchemy/commit/7e1e9e496f04cda635a8166abfc58fd821de2661 feels just as straightforward as any additional feature I could build on top of it. But if you have suggestions for a simple way to incorporate it into the plugin I’d be happy to review a PR.