JohnnyCurran
Allow Floki options to be passed to render_* functions in Phoenix.LiveViewTest
Hello,
The problem: HTML special characters can cause =~ assertions to fail in LiveViewTest - Especially if used in conjunction with libraries that generate random data AKA Faker
Under the hood, all render_* functions in Phoenix.LiveViewTest eventually find their way back to the function Phoenix.LiveViewTest.render/1 which is essentially a wrapper around Floki.raw_html/2
raw_html/2 accepts a list of options (currently only 1 option): a boolean named :encode. If :encode is true (which it is by default), then things such as O'Connell become encoded and rendered as O'Connell in the test. This causes test assertions to fail intermittently.
What’s the current solution?
You can, in config/test.exs, pass config :floki, :encode_raw_html, false which will turn this off for all tests.
In the event we want to enable / disable this behavior for specific assertion(s), we are unable.
I would like to see the ability to do:
assert render(view, encode: false) =~ "O'Doyle"
assert render(view, encode: true) =~ "O'Doyle"
Currently, the only way I can think to do this is expand each of the render_* functions with an optional args \\ [] argument but that seems cumbersome - and there are lots of render functions already.
I welcome all thoughts for or against the idea as well as ideas on how this might be better implemented
Thank you
You can read more about the problem described at Fix Your Flaky Faker Tests - John Elm Labs
First Post!
sodapopcan
I basically just stopped using test data with special chars since I found it too frustrating. A little tangentially I do find it a bit of a footgun since I generally think of LiveView tests of asserting what the user sees, but of course they live in this strange realm between e2es and integration tests.
The simplest option I can think of now that you’ve made me think of it again would be:
assert render(view) =~ Floki.raw_html("O'Doyle")
…which could be wrapped up in an encode or raw helper or something. It might be more flexible if it were:
def encode(string) do
string
|> Floki.parse_fragment!()
|> Floki.raw_html()
end
though I haven’t thought through how that might mess with regexes 
Happy you brought this up!
Popular in Proposals: Ideas
Other popular topics
Latest Phoenix Threads
Latest on Elixir Forum
Sponsor Spotlight
Phoenix, LiveView, multimedia pipelines, distributed systems. 400 engineers, Elixir since 2017. Available for hire.
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
- #elixirconf-us
- #advent-of-code
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #hex
- #security
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 for Elixir devs who love to ship. Start your free account.
Practical resources that improve the lives of professional developers.
Develop your skills with books, videos, and courses.
Enabling companies to succeed by building software people love.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"