-
Notifications
You must be signed in to change notification settings - Fork 9
✨ Add support for find queries in locator fixture #488
Conversation
d5c4eea to
ac532bf
Compare
5602bd7 to
61ab503
Compare
61ab503 to
0aff077
Compare
| expect(text).toEqual(['Hello h1', 'Hello h2']) | ||
| }) | ||
|
|
||
| test('throws Testing Library error when locator times out', async ({queries}) => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Is there any reason why we called this
queriesand notscreen? - @gajus seemed to expose the methods on
Pageitself. Would this be possible? Are we against doing this for some reason?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Both things I have considered... I wasn't sure how much benefit we'd get from attaching stuff to page. From your experience, would this be convenient? We could attach within as well.
That said, I do like how switching to screen would resemble TL. Playwright's Page is like a real "screen," though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I quite like screen for familiarity with Testing Library. And, to be honest, I would prefer to not add any methods to Page as I think this would be unclear (e.g. "why do these methods exist when they're not on the Playwright website?!").
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We adopted the pattern I showed quite without regrets, for what it is worth.
I find that reducing verbosity in tests is extremely important to reduce test fatigue. These things add up
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another idea -- could we leave page untouched but make screen itself be Queries & Page, so it is clear that you are using Testing Library but you do not need to juggle both?
That makes it independent but also reduces verbosity in tests.
Are there issues with doing this? What happens if there is a method that returns a Page? Is there anything we can do to avoid people needing to pass the Locators we produce into within(...) in order to make the Testing Library queries available again?
In practice, being able to chain .locator(...) as you can do in Playwright is quite helpful. My code got more explicit but worse when I used within(...). 😅
(Thinking aloud to see if other's have opinions.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ooo, I quite like that idea re: screen + page. I think I'll probably go that route.
As for your question, we could use a similar approach to augment the Locator returned from queries with the query methods (so you could chain), but my concern there is departing from the Testing Library API.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm think gonna address this stuff in a separate PR.
|
|
||
| expect(text).toEqual(['Hello h1', 'Hello h2']) | ||
| }) | ||
|
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we're going to support Locator#waitFor.state we should add an extra <div> element with a style of visibility: hidden into fixtures/late-page.html which is not added by a setTimeout and is already attached to <body>. That way we could write a test of this passing in state: 'hidden' and state: 'attached' to check the behaviour.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does it make any sense to support hidden and detached just because waitFor supports them? playwright.dev/docs/api/class-locator#locator-wait-for
Right now I'm snagging the type from Playwright, but I'm thinking visible and attached really only make sense https://github.com/testing-library/playwright-testing-library/pull/488/files#diff-04543a94352d1484d0a0add940de7e7b20b0e8d7d58ca1e3aa8d705ba7de95cdR55-R58
Related: waitForElementToBeRemoved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I went ahead and removed hidden and detached from the types for now. Unfortunately our follow-up getBy query for the Testing Library error kinda breaks down when the element is attached but not visible because the getBy query doesn't throw an error in that case 😑.
|
This all looks good to me. I wrote some comments with my understanding of things! (I also wrote further comments within the GitHub issue.) |
ce9630e to
c6a148c
Compare
cb567cb to
739e085
Compare
| )}`, | ||
| ) | ||
| .first() | ||
| .waitFor({state, timeout: 100}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Bleh, this hard-coded timeout is to handle the hidden element case I mentioned where getBy* doesn't throw 😑.
|
I think this may be in a reasonable spot to release as another beta, assuming I can sort whatever's going on with Semantic Release. Worst case we switch to next 🙃 (or maybe alpha, heh) |
|
Can you expose |
(until we have an official API for \`Locator\` queries that doesn't require a **@playwright/test** fixture)
739e085 to
a9cb165
Compare
|
🎉 This PR is included in version 4.4.0-alpha.1 🎉 The release is available on: Your semantic-release bot 📦🚀 |
find*queries in locator fixtureSupportedQuery→SynchronousQueryfind*queries inQueriestype as(/* ... */) => Promise<Locator>locator.first().waitFor()get*querywaitFor's toasyncUtilTimeoutwaitFor'sstateoption into our options and wire it up?hiddenanddetachedjust becausewaitForsupports them? https://playwright.dev/docs/api/class-locator#locator-wait-forwithinto a fixture in order to passasyncUtilTimeoutproperly — @sebinsua is this gonna be annoying/confusing?