On Tue, Jun 4, 2019, at 4:33 PM, Chris Withers wrote: > On 04/06/2019 14:49, Mike Bayer wrote: > > > > > > On Tue, Jun 4, 2019, at 2:15 AM, Chris Withers wrote: > >> Now, what I'm trying to test is that I haven't forgotten to include > >> the "with session.transaction". The problem is that, without the > >> transaction.rollback(), the test passes regardless of whether the > >> "with session.transaction" is there, and with it there, it always fails. > >> > >> What's the best way for writing tests that have the database setup DDL > >> run in a transaction that's rolled back at the end of the session, > >> each test in a subtransaction that gets rolled back at the end of each > >> test, and also test that code under test is committing or rolling back > >> as required? > > > > > > So when you make the Session it has a .transaction that you start with, > > when you come out of your tests, that should be the same .transaction > > when you get the Session back. If it's different, then the test did not > > leave the Session in the same state. does that work ? > > I think what I'm getting to here is that there are two Session instances > here, one that's set up by the web app under test, and one by pytest as > a fixture. > > However, if I understand correctly, they're both running inside the > sub-transaction returned by engine.connect().begin_nested(), which is in > turn inside the transaction returned by engine.connect().begin(). > > So, how do I roll back the further subtransaction created by the web > framework instantiating Session from a sessionmaker bound to the > connection in which begin_nested() has been called, which under non-test > running would actually be a top level transaction assuming I understand > the pattern correctly, in such as way that if the code-under-test has > committed on is session, the session being used to check expectations in > the unit test will see the results, but if it that commit has been > forgotten, it will not?
I'm not following all your code but if there are two sessions in play I'd probably try to avoid that, there should be only one Session you care about. the test fixtures should be external to everything and make sure there's just the one session. if there are two in play, I'm not sure how they both get bound to your test transaction. > > cheers, > > Chris > > -- > SQLAlchemy - > The Python SQL Toolkit and Object Relational Mapper > > http://www.sqlalchemy.org/ > > To post example code, please provide an MCVE: Minimal, Complete, and > Verifiable Example. See http://stackoverflow.com/help/mcve for a full > description. > --- > You received this message because you are subscribed to the Google Groups > "sqlalchemy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sqlalchemy+unsubscr...@googlegroups.com. > To post to this group, send email to sqlalchemy@googlegroups.com. > Visit this group at https://groups.google.com/group/sqlalchemy. > To view this discussion on the web visit > https://groups.google.com/d/msgid/sqlalchemy/471aa85f-776f-b899-1fe8-2f3cc009da38%40withers.org. > For more options, visit https://groups.google.com/d/optout. > -- SQLAlchemy - The Python SQL Toolkit and Object Relational Mapper http://www.sqlalchemy.org/ To post example code, please provide an MCVE: Minimal, Complete, and Verifiable Example. See http://stackoverflow.com/help/mcve for a full description. --- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at https://groups.google.com/group/sqlalchemy. To view this discussion on the web visit https://groups.google.com/d/msgid/sqlalchemy/38abc0c3-6854-42f7-8273-127ea15046c1%40www.fastmail.com. For more options, visit https://groups.google.com/d/optout.
