Problem: when a user joins a group the logging of the newly-created
group membership is broken because the SQL defaults for the membership
haven't yet been generated when the membership is logged:
Added group membership: GroupMembership(id=None, user_id=None, group_id=None, roles=None)
Solution: flush the DB to generate defaults before logging.
If you don't flush the DB you get log messages like this:
Added group membership: GroupMembership(id=None, user_id=None, group_id=None, roles=None)
Tests will tend not to catch this mistake because the test can't
hard-code the auto-generated default values for things like IDs,
datetimes that default to now, etc. So they'll tend to do this, which
passes:
assert caplog.messages == [f"Added group membership: {membership!r}"]
Also it seems that the %r's in log messages are evaluated when the
test accesses caplog.messages rather than when the method-under-test
calls logging.info(). So if the tests do something after calling the
method-under-test that triggers an autoflush (e.g. if the tests do a DB
query after calling the method-under-test) that will cause default
values to be generated. Then when the tests later access
caplog.messages it will contain the generated defaults rather than
None's.
(The %r's also appear to be re-evaluated each time caplog.messages
is accessed so the same log message may at first contain None's then
contain the generated defaults if caplog.messages is accessed at two
different times in the same test!)
Problem: when a user joins a group the logging of the newly-created group membership is broken because the SQL defaults for the membership haven't yet been generated when the membership is logged:
Solution: flush the DB to generate defaults before logging.
Testing:
You should see this logged in the terminal:
Added group membership: GroupMembership(id=, user_id=, group_id=, roles=['member'])
Generally whenever creating a new ORM object you need to flush the DB before logging about it:
If you don't flush the DB you get log messages like this:
Tests will tend not to catch this mistake because the test can't hard-code the auto-generated default values for things like IDs, datetimes that default to now, etc. So they'll tend to do this, which passes:
Also it seems that the
%r
's in log messages are evaluated when the test accessescaplog.messages
rather than when the method-under-test callslogging.info()
. So if the tests do something after calling the method-under-test that triggers an autoflush (e.g. if the tests do a DB query after calling the method-under-test) that will cause default values to be generated. Then when the tests later accesscaplog.messages
it will contain the generated defaults rather thanNone
's.(The
%r
's also appear to be re-evaluated each timecaplog.messages
is accessed so the same log message may at first containNone
's then contain the generated defaults ifcaplog.messages
is accessed at two different times in the same test!)