In yesterday's tip, I shared a bug that surfaced when doing eager loading across database connections.
Even worse, this bug was not visible in local developments or even in the CI pipeline. Embarrassingly, it only showed up when being tested in a QA environment.
The reason?
The local dev environment set the external connection details to match the main default database details.
So when migrations ran, all the tables were created in a single database, and we never ran into the bug.
Our tests happily passed like everything was perfect.
This is yet another cautionary tale proving why it's critical that your local environment should match production as closely as possible.
By collapsing two connections into one, it removed the exact condition that would have surfaced this bug during development.
When I finally tracked down the issue, I didn't jump straight to a fix. First, I updated the local dev environment to use two connections, just like production.
Then I ran the existing feature testsuite and watched it fail. Only after I had a failing test did I apply the fix and verify it passed.
If you're using the RefreshDatabase trait in your tests (which you definitely should!), Laravel only refreshes the default connection by default.
When you add a second connection, you need to tell Laravel about it, or your test data won't get cleaned up properly.
I wrote about exactly how to do that in a previous tip.
Here to help,
Joel
P.S. Have a question about setting up your local environment or testing strategy? Our community is a great place to get help from experienced Laravel developers.
