JonRowe
Better named test helper for building conn for unit tests
The test helpers for creating a conn suitable for unit testing controller helpers and plugs are named in such a way it’s hard to find them. Even as a relatively experienced Phoenix developer bypass_through means nothing to me and I struggled to find it, and even then struggled to use it correctly.
Before I found it I tried:
build_conn()build_conn() |> fetch_flash()build_conn() |> fetch_session() |> fetch_flash()
Before reaching to slack where I was informed of the bypass_through helper and reaching for:
build_conn() |> bypass_through()build_conn() |> bypass_through() |> fetch_flash()build_conn() |> bypass_through() |> fetch_session() |> fetch_flash()
Etc etc you get the idea, what finally worked for me is:
build_conn() |> bypass_through(AppWeb.Router, [:pipeline]) |> get("/")
This is pretty ridiculous when all you want to do is assert a module puts a flash or redirects, in my case I was building a set of extracting authentication helpers to allow me to dry up my controllers. bypass_through is completely “non glanceable” when looking to solve this problem.
Ways to improve
My preferred solution for fixing this is to introduce build_conn_with_pipeline/2 that takes the router and the pipeline, its name will mean its at least findable when looking for this feature set, and can quite happily be built from and point to the more composable existing functions.
An alternate solution is to rename/alias bypass_through as something more obvious, run_pipeline maybe? (Although I’d make it not need the get in that scenario).
A final “least effort” solution, would be to improve the the build_conn documentation and/or error message presented by test helpers operating on a raw build_conn to highlight the need to run bypass_through when doing any kind of non endpoint conn testing…
As per the Github issue I’m happy to open a PR for any of these but I can’t afford to waste my limited open source time building something that that’d be rejected, so opening for discussion first.
First Post!
shanesveller
If the original. deficiency is in the docs, we should start by soliciting and contributing improvements there before introducing another technical abstraction on top of the existing concepts, that may or may not be more accessible to various readers.
Popular in Discussions
Other popular 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
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance









