Repository navigation
test: pin chat listing to a constant number of SQL statements - #46
Merged
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #22
What changed
tests/api/helpers.py:count_statements(session), a context manager that listens to SQLAlchemy'sbefore_cursor_executeon the connection behind thedb_sessionfixture's session and collects every statement sent while the block runs. Route handlers already run on that connection (the fixture overridesDatabase.database_enginewith it), so a request's statements land there.tests/api/test_chat_listing_api.py:test_listing_runs_the_same_number_of_statements_for_one_chat_as_for_manylists chats viaGET /api/chats/for alice (1 direct chat) and carol (5 direct chats), each chat with a last message, and asserts both requests send the same number of statements.tests/api/test_statement_counter.py: checks that a statement on a second connection from a fresh engine is not counted, while one on the test connection is.No changes in
app/, anddb_sessionitself is untouched.Why
No test counted queries, so a regression of the last-message lookup to one query per chat (N+1) would have kept every test green as long as the data was right. Comparing the 1-chat count with the 5-chat count, rather than pinning an absolute number, keeps the test about scaling and leaves the listing query free to change shape.
The listener is registered on the connection object, not the engine class, so other connections (other engines, other tests) are never counted. The counter hooks in through a helper that takes the session, not through a change to
db_session, to stay clear of the parallel fixture-teardown work in #19/#23.How the regression check was done
I temporarily edited
ChatsRepository.list_for_userto droporm.selectinload(tables.ChatsTable.last_message)and load each chat's last message with onesession.get(tables.MessagesTable, chat.last_message_id)per chat (set viaorm.attributes.set_committed_value). Then I ranjust test tests/api/test_chat_listing_api.py:5 chats sent 8 statements (SAVEPOINT, listing SELECT, 5 per-chat message SELECTs, ROLLBACK TO SAVEPOINT) and 1 chat sent 4. I reverted the edit (
git checkout app/). On the unmodified code both requests send 4 (SAVEPOINT, listing SELECT, one batched selectin SELECT, ROLLBACK TO SAVEPOINT) and the test passes.Test results
just test: 112 passed, coverage 100.00%just lint: ruff format/check andty checkall pass