TLDR: Started using Wallaby. Running into some test bugs related to Ecto.Adapters.SQL.Sandbox. Wondering if making an IntegrationCase module is ill advised, or maybe even recommended? Asking because I feel like I can’t foresee all the ramifications well myself. It seems more difficult to know what SQL sandbox related things are happening when using use Wallaby.Feature.

I recently started using Wallaby for part of my tests. I am still digging through the documentation and setting up the first tests.

In the code examples of the documentation the Feature module is used in the tests (i.e., use Wallaby.Feature is declared at the top of a test). The documentation of the Feature module, however, also mentions the following.

If you don’t wish to use Wallaby.Feature in your test module, you can add the following code to configure Ecto and create a session.

setup tags do
  :ok = Ecto.Adapters.SQL.Sandbox.checkout(YourApp.Repo)

  unless tags[:async] do
    Ecto.Adapters.SQL.Sandbox.mode(YourApp.Repo, {:shared, self()})
  end

  metadata = Phoenix.Ecto.SQL.Sandbox.metadata_for(YourApp.Repo, self())
  {:ok, session} = Wallaby.start_session(metadata: metadata)

  {:ok, session: session}
end

As far as I can tell there is no such thing as a IntegrationCase (or whatever name) module in Wallaby, in contrast to Elixir/Phoenix having DataCase, ConnCase and ChannelCase.

I am debugging some test bugs related to how Ecto.Adapters.SQL.Sandbox is setup. I was thinking that having a IntegrationCase would maybe be helpful in that process, because it seems more difficult to know what SQL sandbox related things are happening when doing use Wallaby.Feature.

Is it ill advised for me to make use of an IntegrationCase, rather than declaring use Feature in my test files? I did come across a mention of “IntegrationCase” in this 2017 article by Jake Worth. That’s some time ago, however, so I wanted to check what the status quo is.