unit-tests testapp fixture. how to verify databases changes

[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

[Gerhard Schmidt]

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:

[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.

> --
> 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-discus...@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 <slugg...@gmail.com>

[Gerhard Schmidt]

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:

[Jonathan Vanasco]

> 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.