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 <esta...@augusta.de> 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 pylons-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/pylons-discuss/038969e5-ba94-43cd-aad0-557655c38e0b%40augusta.de.
--
Mike Orr <sluggos...@gmail.com>
--
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 pylons-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/pylons-discuss/CAH9f%3Dupa8QUgOjSxERS-ywsEv06%3DW3SqeKKjbQ6rot%2BKSWq5bQ%40mail.gmail.com.
