defmodule COE.DataCase goes in its own .ex file, and that .ex file should go in test/support. Then, you add test/support to your elixirc_paths in mix.exs
def application() do
[
....
elixirc_paths: elixirc_paths(Mix.env())
....
]
end
# Specifies which paths to compile per environment.
defp elixirc_paths(:test), do: ["lib", "test/support"]
defp elixirc_paths(_), do: ["lib"]
I agree, we need a full guide on testing that covers all of this. The reason it hasn’t been done up to this point is probably because most people using Ash are using it with an app they generated with mix phx.gen which gives you the required setup and scaffolding for this automatically.
AshPostgres is backed by Ecto, and so the underlying logic for sandboxing is handled “below” Ash. We could of course wrap it in something we control, but that would obfuscate more than it would help. Sandboxing in this context is ensuring that each test runs in its own transaction, so that each test does not interfere with the data for another test. Without that, you’d have to clean up data after each test, and make each test run serially.
