Test data is persisting across tests

Questions / Help
,
1

I have discovered something curious: when one test macro creates a row, that row is still visible to another test. I only noticed this occurring because this particular schema is dealing with user-generated primary keys (sort of an ersatz enum – it’s a very small table).

I’m doing a full drop and create before my test runs, so I know that the data isn’t stuck in there from some other process. Here’s my alias from mix.exs:

defp aliases do
  [
    test: ["ecto.drop", "ecto.create", "ecto.migrate", "run priv/repo/seeds.exs", "test"]
  ]
end

I feel like this might be something like threads getting crossed… e.g. if test1 creates a record with primary key “X”, then test2 attempts to create a record with primary key “X”, there’s a problem.

1) test update/2 returns :ok when updating an existing thing (MyApp.Contexts.ThingContextTest)
     test/contexts/thing_context_test.exs:53
     ** (Ecto.ConstraintError) constraint error when attempting to insert struct:

         * thing_pkey (unique_constraint)

     If you would like to stop this constraint violation from raising an
     exception and instead add it as an error to your changeset, please
     call `unique_constraint/3` on your changeset with the constraint
     `:name` as an option.

     The changeset defined the following constraints:

         * thing_id_index (unique_constraint)

     code: status_fixture(%{
     stacktrace:
       (ecto) lib/ecto/repo/schema.ex:689: anonymous fn/4 in Ecto.Repo.Schema.constraints_to_errors/3
       (elixir) lib/enum.ex:1327: Enum."-map/2-lists^map/1-0-"/2
       (ecto) lib/ecto/repo/schema.ex:674: Ecto.Repo.Schema.constraints_to_errors/3
       (ecto) lib/ecto/repo/schema.ex:276: anonymous fn/15 in Ecto.Repo.Schema.do_insert/3
       test/contexts/wholesale_partner_status_context_test.exs:55: (test)

I haven’t run up against this exact behavior even though I’ve done the same type of thing for other modules (i.e. with string primary keys), so I thought maybe it had something to do with how the application was started? My test helper is simply doing ExUnit.start() and I’m doing a simple use ExUnit.Case (no async).

If I run the tests in the module 1 at a time, they all pass, e.g. mix test test/contexts/thing_test.exs:66

Any ideas?

Many thanks for any pointers!

1 Like
2

Have you sandboxing enabled for ecto?

2 Likes
3

I think so. This is my test config:

use Mix.Config

config :myapp,
  MyApp.Repo,
  username: System.get_env("DB_USER") || "postgres",
  password: System.get_env("DB_PASS") || "",
  database: System.get_env("DB") || "myapp_test",
  hostname: System.get_env("DB_HOST") || "127.0.0.1",
  pool: Ecto.Adapters.SQL.Sandbox
4

AHA. I Found it. I had copied and pasted the WRONG repo in my test:

setup do
  :ok = Ecto.Adapters.SQL.Sandbox.checkout(WrongThing.Repo)
end

Should have been

setup do
  :ok = Ecto.Adapters.SQL.Sandbox.checkout(Thing.Repo)
end
1 Like
5

Also I’m pretty sure that a :pool config on the repo doesn’t do anything you should probably drop the pool: Ecto.Adapters.SQL.Sandbox option from there.

1 Like
6

AFAIR this is how it falls out of the generators…

1 Like
7

No, a :pool config is in neither the current config/test.exs or config/config.exs:

Current master config/test.exs:

Current master config/config.exs:

1 Like
8

Its from the generator, but as it seems not from the templates:

$ mix phx.new foo
$ tail -6 foo/config/test.exs
config :foo, Foo.Repo,
  username: "postgres",
  password: "postgres",
  database: "foo_test",
  hostname: "localhost",
  pool: Ecto.Adapters.SQL.Sandbox
1 Like
9

Ah, I see. :pool is configuration for Ecto.Adapters.Postgres: https://hexdocs.pm/ecto_sql/Ecto.Adapters.Postgres.html#module-connection-options

1 Like