fixes panic for the selectOption #1552
Conversation
common/tests/cmd_test.go
Outdated
| const page = await browser.newPage(); | ||
| await page.goto('https://test.k6.io/browser.php'); | ||
| const options = page.locator('#numbers-options'); | ||
| await options.selectOption({label:'Five'}); |
There was a problem hiding this comment.
@ankur22 @inancgumus any tips on how to better test this keeping in mind the current test structure?
I took a look into the tests package and not sure what could be the best way to emulate input like that (and below).
There was a problem hiding this comment.
Basically, I've created this to be like the ones that k6-core uses.
My predominant concern is why it should start from JS is because partially the panic was caused because of some "magic" sobek type transitioning, and I'd like to keep it as part of the test, to ensure that it works
There was a problem hiding this comment.
I really like how you wrote the test, it's much more succinct to how we do it.
If we can't sort the race condition out, then take a look at a test that works with startIteration, such as TestPageOnMetric.
olegbespalov
force-pushed
the
fix/panic-selectOption
branch
from
407f2ef
to
cdc2413
Compare
| if (selectedValue !== 'five') { | ||
| throw new Error('Expected "five" but got ' + selectedValue); | ||
| } | ||
| await options.selectOption({value:'five'}); |
There was a problem hiding this comment.
TODO(olegbespalov): adjust the tests to pick different select options to check that we actually pick the intendant one, but not checking the "five" from the previous working pick
What?
This PR aims to fix the panic from #1415, by trying to stick with the types that we explicitly mention in our documentation https://grafana.com/docs/k6/latest/javascript-api/k6-browser/locator/selectoption/
Why?
We shouldn't panic
Checklist
Related PR(s)/Issue(s)
Closes #1415
Fixes #grafana/k6#4071