You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It is currently a bit challenging to write integration tests for (user) product code which explicitly manages transactions. Since database don't support nested transactions, users can't run the entire test in a transaction and roll it back (to avoid test interference, as can be done with tests which don't manage transactions). This causes the following difficulties:
The database needs to be reverted to its initial state after every test runs, which can be tricky.
Test parallelization must be disabled.
We could provide an IDbContextTransactionManager which "implements" nested transactions as savepoints. That is, if BeginTransaction is called and a transaction already exists, we could create a savepoint instead. This would allow the test to fully manage transactions, but without ever actually committing anything, working around the issues above.
Is there a quick and dirty solution for code that (a) doesn't explicitly set transaction boundaries and (b) tests don't run in parallel?
I recently had a really nice experience with a rails/pg app where tests needed minimal scaffolding (thanks to factorybot), cleaned up after themselves, and ran in good time.
It is currently a bit challenging to write integration tests for (user) product code which explicitly manages transactions. Since database don't support nested transactions, users can't run the entire test in a transaction and roll it back (to avoid test interference, as can be done with tests which don't manage transactions). This causes the following difficulties:
We could provide an IDbContextTransactionManager which "implements" nested transactions as savepoints. That is, if BeginTransaction is called and a transaction already exists, we could create a savepoint instead. This would allow the test to fully manage transactions, but without ever actually committing anything, working around the issues above.
Originally discussed in npgsql/npgsql#3982
The text was updated successfully, but these errors were encountered: