Add simple test infrastructure for testing DB queries #1892
Conversation
This file contains 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.
Especially with the recent review preferences changes, I think that the queries that we run in triagebot are now becoming too complex for them to be tested only in production, and we should start doing at least some basic testing.
There have been previous attempts at introducing more comprehensive tests (#1678, #1698). These were quite large in scope and got stuck discussing various things.
This PR attempts to do something much smaller. It doesn't add full end-to-end tests, but simply enables us to connect to an actual Postgres DB, setup some fixtures and then check that triagebot is doing what we expect it to. Thsi is essentially the same thing that I already do in new bors, with the only difference that there it is handled by sqlx, so it's one line of code :) But given previous discussions in the linked PRs, I wanted to avoid switching to sqlx here.
Note that I don't see any point in testing triagebot against SQLite. A lot of issues that we encounter in production are database and query issues. If we tested against SQLite, we would both have to implement all queries for it, which is additional work, and even then we would be testing something completely different than what gets run on production. Even if we get rid of the more esoteric things that we use now (Postgres arrays), there are still non-trivial differences between SQLite and Postgres (hell, even between different Postgres versions...), so I am quite sute that it wouldn't be worth it. Spinning up Postgres locally with Docker is trivial these days, but I made the tests opt-in anyway, so that it is not even required for running
cargo test.This PR contains a (currently commented out) test for the SQL query which should be hopefully fixed by #1891.
Best reviewed commit by commit. The first commit is the only one that could change production behavior, AFAIK, as the background job now shares the client pool with the main client logic. I think that should be fine, but if you want, I can get rid of that.