RoboZoom
I am trying to configure a Phoenix Ecto app for testing using the example from the docs.
Problem: Each time I run mix test, even when localized to a test that does not require DB access, I receive an error:
16:47:43.083 [error] Postgrex.Protocol (#PID<0.312.0>) failed to connect: ** (DBConnection.ConnectionError) tcp connect (localhost:5432): connection refused - :econnrefused
** (Mix) The database for MyApp.Repo couldn't be created: connection not available and request was dropped from queue after 2000ms. This means requests are coming in and your connection pool cannot serve them fast enough. You can address this by:
Following this error, it appears as if no unit tests are run.
What I’ve done: In my config/test.exs file, I have the following:
config :my_app, MyApp.Repo,
username: "postgres",
password: "password",
hostname: "localhost",
database: "daxta_server_test#{System.get_env("MIX_TEST_PARTITION")}",
pool: Ecto.Adapters.SQL.Sandbox,
pool_size: 10
In my mix.exs file I have:
use Mix.Project
def project do
[
app: :daxta_server,
version: "0.1.0",
elixir: "~> 1.14",
elixirc_paths: elixirc_paths(Mix.env()),
start_permanent: Mix.env() == :prod,
aliases: aliases(),
deps: deps()
]
end
def application do
[
mod: {MyApp.Application, []},
extra_applications: [:logger, :runtime_tools]
]
end
# Specifies which paths to compile per environment.
defp elixirc_paths(:test), do: ["lib", "test/support"]
defp elixirc_paths(_), do: ["lib"]
Within test/support I have a file repo_case.ex where I checkout the SQL sandbox, but for the test I’m running I don’t call this, as I am not testing anything Ecto related.
I received a suggestion to add the --no_start tag to the mix test command, but that sounds hacky. I’m sure that there’s a better way to set this up, and I’m just missing some fundamental configuration setting.
Any help is appreciated!
Trending in Questions
Other Trending Topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #blog-post
- #phoenix_html
- #iex
- #graphql
- #ai
- #genstage
- #elixirconf-us
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #security
- #hex











First 5 of 5 Posts
al2o3cr
The default
mix.exscreated by the generators has this task alias:The message you’re getting suggests that the
ecto.createstep is failing before any tests even get a chance to run.jarlah
Or, if you need database and dont want to mess around with scripts or commands, you can use Testcontainers for Elixir. Until you start adding tests with db access this will just work in the background. Its a bit rough around the edges still, but its getting there. I’m currently working on it and any suggestions are appreciated.
RoboZoom
This is indeed what the generator auto-created for me.
Which leads me to question - what is the purpose of
ecto.createorecto.migratein the test context? Ecto’s own instructions indicate that you can mock the database via the Sandbox.It makes sense that the migrate command requires a connection - is it normal to test without some sort of test database setup?
al2o3cr
The Ecto sandbox doesn’t mock the database, it wraps each test in a transaction so that they don’t interfere with each other. You still need a database underneath.
jarlah
that’s also why I suggest using testcontainers when making Phoenix apps. It’s less of a chore to add a couple of lines at the top of the start function in application.ex, than playing with scripts or manual docker commands, and you don’t even need to have docker installed, because Testcontainers for Desktop now has embedded runtime. The test container also shuts down if tests are completed naturally, due to use of System.at_exit. If tests are aborted, it’s cleaned up by a reaper process in docker (started by testcontainers). Ill shut up now