Setting Up Sandbox Mode

Testing Elixir — by Andrea Leopardi, Jeffrey Matthias (44 / 80)

👈 Testing Your Schema Through Database Calls | TOC | Wrapping Up 👉

Our database keeps state, and right now this test is leaving new rows in the database. In the short run, it’s very unlikely to create a problem because we’re using a new, random string every time we run the test. In the long run, having persistent data between test runs increases the likelihood of having test failures due to unforeseen data collisions. If the same random string did happen to be picked in different test runs, the test would fail on the first inserted user, which was supposed to be part of the setup.

Working against your database in tests is one of the most common places where leftover state changes can cause problems. We managed to avoid issues with our test on the unique constraint by using randomized data. But even with that, every successive test run is leaving one new row in the database. Each test works best when operating in a known good environment because that’s the only way they can guarantee that their own setup is complete and reliable. If a test can’t assume a clean working environment, we need to write a lot more defensive code, checking the environment for existing data, instead of just making what’s needed for the test and moving on. This approach both slows down writing the tests, because more code is needed, but it also slows down the tests themselves. While an extra database check or two isn’t really an issue…