coen.bakker
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.Featurein 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.
Trending in Questions
Other Trending Topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #blog-post
- #elixirconf-us
- #elixir-ls
- #ai
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming











Showing Posts 1 to 4- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
krasenyp
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.
coen.bakker
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.I am working my way through the part of the
WallabyandEcto.Adapters.SQL.Sandboxdocumentation about the different possible modes of a sandbox pool. I am still in the process of wrapping my head around the ownership mechanism.coen.bakker
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.FeatureCaseORuse Wallaby.Featuresomehow. I am now using theFeatureCasedescribed in the TDD Phoenix book. I my case I don’tuse Wallaby.Feature. However, I have also seen approaches thatuse Wallaby.Featureinside aFeatureCase. 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.mhanberg
If you want proper screenshots on failure, you’ll still want to use the feature macro by importing Wallaby.Feature