JohnnyCurran
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
Where Next?
Trending in Proposals: Ideas
Other Trending Topics
Latest Phoenix Threads
Latest on Elixir Forum
Sponsor Spotlight
Elixir, Erlang & messaging conferences from Code Sync. Next up: ElixirConf US (10–11 Sep) & Code BEAM Europe (21–22 Oct), Haarlem + online.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #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
- #elixirconf-us
- #ai
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #hex
- #security
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Practical resources that improve the lives of professional developers.
Master modern tools, write cleaner code, and tackle real-world challenges.
The deployment platform built for Elixir: PaaS ease, VPS control.
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 1- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
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:
…which could be wrapped up in an
encodeorrawhelper or something. It might be more flexible if it were:though I haven’t thought through how that might mess with regexes
Happy you brought this up!