ijdickinson
I’m writing a Wallaby test for a select element that looks something like this:
<select id="status-select" name="status">
<option selected="" value="b9259ffd-a2de-488f-85f0-567d1e9a7159">new</option>
<option value="f56f5249-0920-4747-8e89-e8b07ba1a5e8">assigned</option>
</select>
The value attributes on the options are auto-assigned each time by the back-end system. So in order to be able to call Wallaby.Browser.set_value/3, I need to first query the page to find the current value for the option. My code to do that is:
value_fixture = Browser.find(
session,
Query.css("#status-select > option:nth-child(2)", visible: false)
)
|> Element.attr("value")
If I execute the query expression in the browser console with a document.querySelectorAll(), it finds the right element for me.
But Wallaby doesn’t:
** (Wallaby.QueryError) Expected to find 1 invisible element that matched
the css ‘#status-select > option:nth-child(2)’, but 0 invisible elements were found.
Is there some other way to query the options of a select using Wallaby that I should be using?
Where Next?
Trending in Questions
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
Deploy Phoenix to your own VPS with PaaS ease: push-to-deploy, zero downtime, auto SSL, managed Postgres. 14-day free trial at potions.io
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
- #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.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Bringing learning, work and compliance together since 1987.
**Building the future of software with AI, trust, and human connection.**
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 5- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
michallepicki
web drivers sometimes work in mysterious ways, did you try without
visible: false?ijdickinson
Argh. PEBCaK!
My fixture set-up had a bug, so the page that Wallaby was seeing didn’t actually have the set of statuses it should have have, and so the
:nth-child()sub-expression was failing.Doh.
vanderhoop
A couple questions.
value. Depending on what you’re trying to test (just that the values are presented as options), you may be able to move this test out of wallaby entirely.click(css("option[value=theValueIWantToSelect]"))ijdickinson
The goal is to be able to select an option in a select element, where the
valueattribute of the option can only be known at run time. In your example:the actual value of
theValueIWantToSelectwill change each time the page is built. Hence the first step in writing the test is to query the page to get the current value of the option’svalueattribute, and then to use that value in a call toBrowser.set_value, which emulates the user’s interaction. Or, indeed, callclickas in your example.ijdickinson
One final note for future reference: although it’s not (afaics), mentioned in the docs, but when setting the value of a
selectelement,Wallaby.Browser.set_value/3needs the text of theoptionto select, not the value.