My team uses an umbrella project with, among other “standalone” applications, a Phoenix 1.3 app.
Running mix test from the umbrella root causes the phoenix app’s test to be run, meaning a postgres db has to be set up for every developer (including those not working on the phoenix app at all.)
This is a bit cumbersome, so I though about using an “in memory” / “install-less” DB for tests on a developer local machine by default (clearly, our CI server would still run the tests against a realpostgres database.)
What would be options to do that, knowing that sqlite is not an option at the moment, since unfortunately (at the time of writing) the sqlite_ecto lib has not been upgraded to Ecto 2 (there are some efforts on this front, but it does not seem to work in my case ?)
I don’t think using a different database in dev & production is the solution - it definitely isn’t if you use any of the interesting features of Postgres.
A simple solution might be to use @moduletag :db in the test case modules that require database (can be further automated with templates), and running mix test --exclude db to skip the tests that require the database.
That might still lead to issues, if applications themselves require connection to database.
This feels like a recipe for disaster IMHO. Having a different DB in dev vs prod is going to hamstring your webapp team by essentially locking them out of all of PostgreSQL’s more advanced features…that constitute the bulk of the selling points for using it.
If the mix test --exclude db solution doesn’t work I’d strongly suggest continuing to use PG locally. Between the Docker option and even https://postgresapp.com/ if you’re developing in OSX it shouldn’t be a huge commitment.
I pretty much agree with everything others have said. Using the same db for local dev, testing, and prod is the best solution.
If setting up dbs is challenging, consider simplifying it with e.g. docker. At work, we use dockerized DB for dev/tests, and even have some helper scripts to start them and conditionally prime them. As a result, setting up of the dev env is almost completely automated. In particular, no custom configuration (such as creating users, creating databases, permissions, etc.) is required.
I understand your concerns about differences in DB implementation.
However, I am at a point of the project where we don’t use the DB at all (not yet), but due to the strong expectation on phoenix side that a DB is running, it impacts everyone working on most of our projects, even though they don’t (and should not) care about a DB.
