pinksynth

pinksynth

Whenever tests have to interact with an Ecto.Repo, sometimes it’s necessary to test a few different branches or paths that data can take. This can be tedious with a database and may result in “resetting” records so they may be re-tested. Here’s a crude example of “resetting” some data to continue with a test:

test "vaccinate_dog/1 vaccinates dog and creates vax record with the corresponding name" do
  dog = dog_fixture()
  
  # Perform assertions about vaccinations
  assert :ok = vaccinate_dog(dog, "bordetella")
  assert %{id: dog_id, vaccinated: true} = dog = Repo.one!(Dog)
  assert %{dog_id: ^dog_id, type: "bordetella"} = Repo.one!(Vax)

  # Reset state for the dog
  Repo.delete_all(Vax)
  dog |> Ecto.Changeset.change(%{vaccinated: false}) |> Repo.update!()

  # Performmore  assertions about vaccinations
  assert :ok = vaccinate_dog(dog, "rabies")
  assert %{id: dog_id, vaccinated: true} = dog = Repo.one!(Dog)
  assert %{dog_id: ^dog_id, type: "rabies"} = Repo.one!(Vax)
end

By using Repo.transaction/2, it’s easy to simply roll back a transaction rather than “resetting” anything (assuming that side-effects are not a concern for the purposes of the test.

test "vaccinate_dog/1 vaccinates dog and creates vax record with the corresponding name" do
  dog = dog_fixture()

  for vaccine <- ["rabies", "bordetella"] do
    in_transaction(fn ->
      assert :ok = vaccinate_dog(dog, vaccine)
      assert %{id: dog_id, vaccinated: true} = dog = Repo.one!(Dog)
      assert %{dog_id: ^dog_id, type: vaccine} = Repo.one!(Vax)
    end)
  end
  
  defp in_transaction(fun) when is_function(fun, 0) do
    Repo.transaction(fn ->
      fun.()
      Repo.rollback(:ok)
    end)
  end
end

I know that it’s generally best to decouple the DB and the business logic as much as possible, but I have found this to be a useful way to succinctly cover more ground within Repo-related tests.

Showing Posts 1 to 2

al2o3cr

al2o3cr

This is usually where I’d stop this test and write another one, TBH. Unless dog_fixture is very expensive to compute, I’d prefer to see duplication if testing with "rabies" vs "bordetella" exposes different behavior.

Also note there’s no support AFAIK for nested transactions, so this won’t work as expected if used with the sandbox-enabled test harness that’s generated by Phoenix.

pinksynth

pinksynth OP

Yeah, admittedly this is not the best example. My actual use case is a module which does some pretty complex query composition using “filters” that can be manipulated recursively by the end user and is generally in the “hard to test” world of high-CC code. I don’t recall the specifics of how our Repo is set up in tests but we use transactions like this quite a bit and they all seem to work fine :grimacing:

— All posts loaded —

Where Next? Top

Trending in Guides/Tuts Top

krasenyp
You probably already know that &lt;span&gt;{nil}&lt;/span&gt; in a HEEX template produces &lt;span&gt; &lt;/span&gt; when rendered. I fin...
New

Other Trending Topics Top

sorenone
Oban v2.24.0 has been released. This release unifies configuration for queues, repos, and services, swaps opaque timing integers for rea...
New
garrison
Hobbes is a low-level distributed database for the Elixir programming language. Hobbes provides a simple, safe, and scalable storage lay...
New
mcass19
ExRatatui lets you cook up rich terminal UIs in Elixir, powered by Rust’s ratatui via Rustler NIFs. Build interactive terminal applicatio...
New
Damirados
Hello everyone. After busy few months I am happy to announce v0.1.0 of Emerge &amp; Solve. They are GUI (Emerge) and State management (S...
New
netoum
Corex is an accessible, unstyled UI component library for Phoenix that integrates Zag.js state machines using Vanilla JavaScript and Live...
New
wintermeyer
There are three potential reasons for members of this forum to have a look at https://vutuv.de You are tired or annoyed of LinkedIn. Yo...
New

We're in Beta

About us Mission Statement

Options

Thread Display Mode




Thread Preview

Skip Thread Previews