I’m working on a side project that uses Discord for authentication and connects to a PostgreSQL database. Once I got the login flow down, it’s super hard to resist the urge to start implementing other features as fast as possible. I mean it’s a side project, right?
Yet, I can’t shake a nagging feeling, that I should be testing what I made. So I took some time to think about it.
Testing can get a bit confusing. I had courses that emphasized testing, but it didn’t feel like I developed a good understanding of testing strategies that created a concise appreciation of when to test, how to test and how to cleanly structure those tests.
Oddly enough my favorite experience in testing was creating our West In Progress game in Godot. Using a Godot framework, creating tests for each class and function was neatly organized. With multiple people working on the project, it was great to merge, hit the test button, and look to see if any of the class functions broke. I wanted something similar for this project.
I’ve only developed two sets of operations currently: user and session. I decided to start with the users since in the flow, a session is only created when a user has been approved.
In the api directory, there’s a tests directory. Since we’re using FastAPI, this is using pytest. I started really basic with testing the endpoints of the api checking for 200 and 404 responses, then I moved on to attempting the user operations.
Along the way, it was said that creating a test database is good practice as to not interfere or possibly corrupt the production database. I created a test postgresql database, and that was actually fun. When the tests run, they create the needed tables, populate it with fake user data, and then drop the tables at the end.
For now, the test_user_operations.py is getting quite large. If you noticed in the api/database/operations directory, I actually split each function into its own file, attempting to follow the single purpose principle. It also makes it easier to focus on the function at hand.
I’d like to take the single purpose approach for the user tests, but I’m still fighting the learning curve for the tests themselves.
