> While debugging, I found that there is a different dbsession in the
request object inside the testapp call than in the test function.
Yes, that is expected.
The TestApp encapsulates the application and the entire request lifecycle
as if it were a normal application. The session is created and bound to
the Pyramid request within the testapp as if it were a normal pyramid
request. The scope of that session is within the request. The session
should be closed and cleaned up as part of the request finalization. In
other words, the Pyramid request and session both live exclusively within
the `testapp.post('/config/mails/instance_removal_imminent')`; once that
`response` is generated and returned to the client, they are gone.
The inability to query for the object is probably due to the unittest and
testapp having different databases. If they are using sqlite:memory, then
they will both have different unique in-memory databases. A way around
that is to switch tests to a filebacked sqlite or a RDBMS.
To handle some tests like what you are doing, I have leveraged
pyramid_debugtoolbar and custom panels. You could make a custom panel that
generates a machine-readable report for each request - then make two
requests for each test -- one against the app, and one for the debugtoolbar
info as parsed from the app's response.
If you wanted to do a risky test, you might be able to have the test suite
monkeypatch the application's session creator into a function that uses the
unittest's session. personally i would avoid that, as it would leave the
normal session generation untested.
> You can also refactor your low-level database routines into functions
that take a 'session' argument, so that you can pass a session
directly and you don't need a request object. And maybe the functions
return standard lists and dicts rather than SQLAlchemy row proxies or
ORM objects, to avoid lingering dependencies on the session state that
may no longer be there.
+1 to all of these suggestions.
On Friday, June 14, 2024 at 8:29:18 AM UTC-4 Gerhard Schmidt wrote:
> As I said. The sqlalchemy session is no longer a problem.
>
> It's the session object of the request I would like to access in the
> unit-test.
>
> Regards
> Estartu
>
> Am 11.06.24 um 18:42 schrieb Mike Orr:
> > I don't know the answer directly, but that commonly occurs in test
> > suites and you have to find a way around it. It sounds like you're
> > using a default Pyramid SQLAlchemy configuration where the session and
> > connection are initialized by hooks during the request process, and
> > finalized before the request ends. So by the time you check the
> > result, the session is already gone. Or sometimes what happens is the
> > session is committed/rolled back and the ORM objects are no longer in
> > the session, or if you have a separate reference to the objects you
> > find they're no longer tied to an active session, so relations or
> > calculated fields no longer work. (E.g., 'user.addresses', but the
> > live relation and the Address instances are gone.)
> >
> > The way around this is to create the session before invoking the
> > request, and pass it as an argument to the tested code, and don't let
> > any hooks interfere with it.
> >
> > If your production workflow has a 'request.sa_session' property that
> > instantiates a session on the fly and at the end commits it (e.g.,
> > using 'zope.sqlalchemy' and 'transaction'), or you have a Request
> > subclass that does the equivalent, then you replace that property or
> > the entire Request object with a substitute that has your test session
> > in the attribute; e.g.,
> >
> > sess = sqlalchemy.orm.Session(bind=engine)
> > request.sa_session = sess
> > result = test_function(request)
> >
> > You can also refactor your low-level database routines into functions
> > that take a 'session' argument, so that you can pass a session
> > directly and you don't need a request object. And maybe the functions
> > return standard lists and dicts rather than SQLAlchemy row proxies or
> > ORM objects, to avoid lingering dependencies on the session state that
> > may no longer be there.
> >
> > On Tue, Jun 11, 2024 at 12:37 AM Gerhard Schmidt <[email protected]>
> wrote:
> >>
> >> Ok forget the first question. I've transplanted the pytest folder from a
> >> new pyramid project into an existing one that was created when unittest
> >> was used.
> >>
> >> Missed some changes in models.__init__.py. After transplanting them, it
> >> works.
> >>
> >> But the second question remains. Is there way to access the session
> >> after the testapp request is finished.
> >>
> >> Regards
> >> Estartu
> >>
> >> Am 11.06.24 um 08:18 schrieb Gerhard Schmidt:
> >>> Hi,
> >>>
> >>> im doing some unit testing. The following test works fine
> >>>
> >>> def test_template_submit_functional(testapp, dbsession):
> >>> test_data = (('subject', 'Das ist ein test'),
> >>> ('plain_body', dummy_text),
> >>> ('form.submit', 'Speichern')
> >>> )
> >>>
> >>> response = testapp.post('/config/mails/instance_removal_imminent',
> >>> params=test_data, status=302)
> >>>
> >>> assert response.location ==
> >>> 'http://example.com/config/mails/templates'
> >>>
> >>> The call should create an entry in the database.
> >>>
> >>> When i try to find the object via dbsession.query() nothing is found.
> >>>
> >>> I've done single step debugging and the view function is executed
> >>> correctly and all changes to the database are there.
> >>>
> >>> While debugging, I found that there is a different dbsession in the
> >>> request object inside the testapp call than in the test function.
> >>>
> >>> Another question. Is there a way to access the session object to verify
> >>> changes there.
> >>>
> >>> Regards
> >>> Estartu
> >>>
> >>
> >> --
> >> You received this message because you are subscribed to the Google
> Groups "pylons-discuss" group.
> >> To unsubscribe from this group and stop receiving emails from it, send
> an email to [email protected].
> >> To view this discussion on the web visit
> https://groups.google.com/d/msgid/pylons-discuss/038969e5-ba94-43cd-aad0-557655c38e0b%40augusta.de
> .
> >
> >
> >
>
--
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/pylons-discuss/49c77d81-d806-4695-a20f-45f2d0e8f1e1n%40googlegroups.com.
