Creating IntegrationCase recommended over `use Wallaby.Feature`?

Phoenix Forum Questions / Help
, , , ,
1

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.

2

It would be helpful to share what are the bugs you’re encountering. Without this context, I don’t really understand the question and can’t help. Maybe you can check German Velasco’s book about testing Phoenix - https://www.tddphoenix.com/, it uses Wallaby.

1 Like
3

Thank you for the reference to the book. I think it will come in very handy. I already spotted that it goes into setting up a FeatureCase.

The errors I am running into are ownership errors: ** (DBConnection.OwnershipError) cannot find ownership process for #PID<0.xxx.0>. Specifically, I am running into an error when registering a user through the UI.

defmodule AppWeb.FirstFeatureTest do
  use ExUnit.Case, async: true
  use Wallaby.Feature
  alias Wallaby.Query

  @username_field Query.text_field("Username")
  @email_field Query.text_field("Email")
  @password_field Query.text_field("Password")
  @log_in_button Query.button("Sign in")
  @register_button Query.button("Create an account")

  feature "temp", %{session: session} do
    session =
      session
      |> visit("/users/register")
      |> fill_in(@username_field, with: "username")
      |> fill_in(@email_field, with: "username@example.com")
      |> fill_in(@password_field, with: "password1234")
      |> click(@register_button)

    :timer.sleep(200)
    take_screenshot(session)
  end
end

I am working my way through the part of the Wallaby and Ecto.Adapters.SQL.Sandbox documentation about the different possible modes of a sandbox pool. I am still in the process of wrapping my head around the ownership mechanism.

4

Having read more of the TDD Phoenix book and learnt about approaches to setting up a FeatureCase, I want to make sure not to confuse beginners with my original post.

To be clear, I made it seem in my post as if you need to choose between use.FeatureCase OR use Wallaby.Feature somehow. I am now using the FeatureCase described in the TDD Phoenix book. I my case I don’t use Wallaby.Feature. However, I have also seen approaches that use Wallaby.Feature inside a FeatureCase. For example, see this blog by Britton Broderick.

I choose the former approach, because I like to include this code snippet in my FeatureCase, instead of hiding it inside use Wallaby.Feature.

5

If you want proper screenshots on failure, you’ll still want to use the feature macro by importing Wallaby.Feature

1 Like