polypush135
I wanted to know if this is a good patter for setting up a context in ExUnit with phoenix?
This test is using ConnCase so from the looks of it, the ConnCase setup runs first and then is followed by the setup inside the test file.
Thoughts on how to improve this pattern?
defmodule Opalnova.PostControllerTest do
import Opalnova.Factory #note using ex_machina via insert(:post)
use Opalnova.ConnCase
...
setup context do
case context do
%{with_post: true} ->
{:ok, %{conn: context.conn, post: insert(:post) }}
_ ->
:ok
end
end
test "lists all entries on index", %{conn: conn} do
conn = get conn, post_path(conn, :index)
assert html_response(conn, 200) =~ "Listing posts"
end
...
@tag :with_post
test "renders form for editing chosen resource", %{conn: conn, post: post} do
conn = get conn, post_path(conn, :edit, post)
assert html_response(conn, 200) =~ "Edit post"
end
end
the {:ok, %{conn: context.conn, post: insert(:post) }} feels dirty
Where Next?
Trending in Discussions
Other Trending Topics
Latest Phoenix Threads
Latest on Elixir Forum
Sponsor Spotlight
Practical resources that improve the lives of professional developers.
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
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #blog-post
- #ai
- #elixirconf-us
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Practical resources that improve the lives of professional developers.
Master modern tools, write cleaner code, and tackle real-world challenges.
Bringing learning, work and compliance together since 1987.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 3- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
karmajunkie
I don’t think there’s anything inherently wrong with it—its an interesting technique I haven’t seen before, actually, and I can see that it might be useful sometimes. But in this case, I think you’re better off just duplicating the
insert(:post)in the tests that need it rather than being clever with tags. If you find that the duplication gets more complex, i would probably split my test into two different files where each test in the file uses the same setup scenario. The cognitive load in connecting the tag with your setup is kind of high for what I see as a small savings.Just my two cents, YMMV…
polypush135
I agree with your assessment and maybe my example is contrived.
To give you a little more back ground, I’m coming from ruby + rspec and I was looking for something comparable to rspec’s let + context block. I wanted to find a way where setup could be identifiable as only useful in a given context.
karmajunkie
Yeah, coming from a heavy Ruby background myself I can see where you were coming from. I think you’ll probably find that in the general consensus in Elixir is that rspecs let and nested contexts do more to detract from maintainability than they help, so they’ve been left out by intention.
What you might try instead of tag-based setup is to collect repetitive setup steps into a set of functions you can call to quickly init a given scenario, leaning less on the setup context. Those can also be moved into an imported module for use across tests if needed.