I’m currently working on developing event RSVP functionality for dmvboardgames.com. Initially, I decided to have separate database tables for users with edit permissions on an event and people who have an RSVP to attend an event.

However, I ran into challenges because of the need to query both tables to display information about an event. Event hosts should have permission to edit an event, and they should also be automatically counted as an event RSVP. Also, event hosts should not have the ability to directly update their RSVP like a regular user, and they should have another UI to step down as event host or make someone else the host.

To simplify the code and the database, I decided to combine event rsvp and event editor permissions into one table. After updating the schema on my local environment, I ran the integration tests, which unsurprisingly had test failures. Within approximately 15 seconds, the test results identified which areas of the code needed to be updated. This will be especially useful for developers who haven’t been closely working with the codebase for months.

I also added a test case to verify that a standard user could not modify an event. Then I set the test to automatically fail as a placeholder until I created the test. This was a reminder that this test had to be run before a production deployment. When attempting to create a build for a production deployment, the build will fail if there are any test failures.

After updating queries and deleting some code, the tests passed. Aside from simplifying the code and database design, the performance was better because I was able to get rid of an extra database query when retrieving event RSVP data.

On the other hand, I maintain a copy of the database schema definition for the unit tests that is not automatically synced with the database migrations that were run in production. There are a large number of migrations that have run, and some of them involve schema changes to existing tables. Running these migrations to set up a test database would make the tests take significantly longer to finish. Each test file recreates the database schema and test data to help ensure that tests aren’t affected by other tests. Manually copying the relevant schema changes is also less complex than an automated copying process.

Also, the local development environment uses the same copy of the database schema definition. This allows for manual testing to help verify that the test schema is in sync with the production schema.