Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Future of this library #558

Open
IanVS opened this issue Oct 9, 2022 · 10 comments
Open

Future of this library #558

IanVS opened this issue Oct 9, 2022 · 10 comments
Labels
help wanted Extra attention is needed question Further information is requested

Comments

@IanVS
Copy link

IanVS commented Oct 9, 2022

Hi, I see that playwright has released an API very similar to testing-library in https://github.com/microsoft/playwright/releases/tag/v1.27.0. I'd like to get your take as maintainers of this library. Is there still something this library can offer over the native playwright API? If I'm deciding what to use on new playwright tests, what would you recommend? Thanks!

@jrolfs jrolfs added help wanted Extra attention is needed question Further information is requested labels Oct 11, 2022
@jrolfs
Copy link
Member

jrolfs commented Oct 11, 2022

Hi @IanVS, thanks for the heads up here. Damn, good thing I didn't build a business on this library 😝.

On a more serious note, let me try to provide an objective take on what this means for playwright-testing-library. I haven't played with the new API yet, but going off of the documentation, this is what differentiates this library from the new, native, Playwright offering:

  • This library is still more "true" to the original Testing Library API
    • It uses DOM Testing Library under the hood (as a selector engine) so the behavior should always be consistent with DOM/React Testing Library, etc.
    • Playwright does not include the *AllBy* queries for selecting multiple elements
    • Playwright does not differentiate query* and get* queries
    • Playwright does not include the asynchronous find* queries
    • Because this library uses DOM Testing Library and its types under the hood, it will continue to track the Testing Library API as it changes over time (though, I suspect it won't change a ton going forward)
    • Playwright does not support function-based TextMatch (although our current implementation does have this limitation)
  • This library supports asynchronous queries (find*) in query chains, which makes chaining a bit more powerful as it incorporates Locator.waitFor() into the chain ← 👋🏻 — this is probably the biggest differentiator right now, as I see it

From what I can tell, the advantages of using this library are admittedly somewhat limited. As I pointed out above, I think the find* queries are probably the biggest differentiator. When combined with query chaining, I think they are pretty powerful. I was planning on continuing to improve the chaining API as well. That said, I think you can accomplish everything that this library provides with the new Playwright API, albeit with a bit more verbosity and a bit less "idiomatic Testing Library" if you will. The native Playwright queries may also have better performance characteristics.

As for the future of this library, I think I'll have to do some more tinkering and thinking to provide a more definite answer. Hopefully, the comparison above gives you enough information to make a decision. I also hope we can get some other takes in here. I'm fully committed to continuing to maintain this library if the community thinks it's worth it (including continuing to add features that may never make it into native Playwright).

I'll update this issue as my thinking/research evolves. Let me know if you have any specific questions, though!

@IanVS
Copy link
Author

IanVS commented Oct 11, 2022

Thanks for the thoughtful and detailed answer! I do enjoy the find* queries, so I'll need to think on this. 🤔 It seems like the decision comes down to being able to write the exact same kinds of queries as my other component tests use, vs a native solution that doesn't require an extra dependency. It will also be interesting to see what other improvements might be coming to Playwright over time. It sounds like it might be worth having a bit of a discussion with their devs to see whether they're planning to implement the other Testing Library methods eventually.

As another heads-up, there was some discussion in Twitter as well, which I'd be curious to get your thoughts on: https://twitter.com/phry/status/1578687964682801153.

Thanks for all your hard work on this package. I'm really excited about the prospect of using Testing Library methods in Playwright tests one way or another. I think it will be a powerful combination.

@jrolfs
Copy link
Member

jrolfs commented Oct 11, 2022

@sebinsua any chance you have some good real-world example cases where you've been reaching for find* queries? The more I think about this, the more I'm sorta leaning towards recommending people switch to this new native query API. As nice as it is to have API parity with DOM Testing Library. The find* queries really are what sets this library apart from the new Playwright stuff, and as we've discussed before, they are a bit confusing when used with Locator on account of Locators being inherently lazy/async.

@IanVS I think this is what I'd recommend since it sounds like you're starting a fresh project:

  1. Start out without playwright-testing-library and see how the new Testing Library API in 1.27 serves you
  2. Keep the find* queries in mind and drop an example in this issue if/when you find yourself reaching for a find* query and we can use that to decide whether that's really what makes the most sense

Perhaps the future of this library is a lighter-weight version that simply fills that gap. In that case, I'd probably also open an issue upstream to see if we can just contribute it directly to Playwright. I suspect they may be reticent on account of this:

they are a bit confusing when used with Locator on account of Locators being inherently lazy/async.

Either way I don't want to leave anyone hanging that did adopt this library in some form. I'm down to continue maintaining it in its current form and/or provide migration guidance. However, what we decide here will determine whether I will continue with 5.0 as I had originally planned.

@jrolfs
Copy link
Member

jrolfs commented Oct 11, 2022

Here's a comparison table for the available queries. I think all of the missing Playwright query functionality can be accomplished via other APIs:

  • Asynchronous find* queries → get* query + await locator.waitFor()
  • Errors thrown by get* queries → implicitly thrown upon interaction with missing element or locator.count()
  • Querying for multiple elements with *AllBy* queries → locator.nth(1), locator.count(), etc. (Playwright native get* queries return all matched elements minding strictness)
Query Playwright 1.27+ Playwright Testing Library
ByPlaceholderText ☑️ ☑️
queryByPlaceholderText Locator
queryAllByPlaceholderText Locator
getByPlaceholderText Locator Locator
getAllByPlaceholderText Locator
findByPlaceholderText Promise<Locator>
findAllByPlaceholderText Promise<Locator>
ByText ☑️ ☑️
queryByText Locator
queryAllByText Locator
getByText Locator Locator
getAllByText Locator
findByText Promise<Locator>
findAllByText Promise<Locator>
ByLabelText ☑️ ☑️
queryByLabelText Locator
queryAllByLabelText Locator
getByLabelText Locator Locator
getAllByLabelText Locator
findByLabelText Promise<Locator>
findAllByLabelText Promise<Locator>
ByAltText ☑️ ☑️
queryByAltText Locator
queryAllByAltText Locator
getByAltText Locator Locator
getAllByAltText Locator
findByAltText Promise<Locator>
findAllByAltText Promise<Locator>
ByTestId ☑️ ☑️
queryByTestId Locator
queryAllByTestId Locator
getByTestId Locator Locator
getAllByTestId Locator
findByTestId Promise<Locator>
findAllByTestId Promise<Locator>
ByTitle ☑️ ☑️
queryByTitle Locator
queryAllByTitle Locator
getByTitle Locator Locator
getAllByTitle Locator
findByTitle Promise<Locator>
findAllByTitle Promise<Locator>
ByRole ☑️ ☑️
queryByRole Locator
queryAllByRole Locator
getByRole Locator Locator
getAllByRole Locator
findByRole Promise<Locator>
findAllByRole Promise<Locator>
ByDisplayValue ☑️
queryByDisplayValue Locator
queryAllByDisplayValue Locator
getByDisplayValue Locator
getAllByDisplayValue Locator
findByDisplayValue Promise<Locator>
findAllByDisplayValue Promise<Locator>

@vid
Copy link

vid commented Jan 25, 2023

I am working on an approach where pluggable testing implementations run under Jest. From what I can see, Playwright's tests prevent this from happening. If I understand correctly, this library doesn't, so in that regard it is immeasurably more useful.

@jrolfs
Copy link
Member

jrolfs commented Feb 2, 2023

@vid I'm curious — could you provide a bit more detail for your use case? Since Playwright shipped the native Testing Library queries in 1.27, I'm not planning on actively developing this library, but I do plan to continue to support it.

@vid
Copy link

vid commented Feb 7, 2023

I may be wrong, but on a cursory exploration I had the impression playwright's testing library could only be used in its own framework, it throws an exception if trying to use it under Jest. If I'm wrong, if I can use its testing method like any other method, no problem!

@vid
Copy link

vid commented Feb 9, 2023

I was wrong, the way I am using these function what Playwright offers suits my library. Sorry about the distraction!

@jrolfs
Copy link
Member

jrolfs commented Feb 10, 2023

No worries :)

@GermanJablo
Copy link

I don't think anyone has mentioned the most important difference yet: playwright components requires launching a real browser in each test.

I haven't done benchmarks, but this should be much slower (if anyone can share their experience with numbers that would be cool).

I have opened an issue in Playwright precisely to solve this problem:

microsoft/playwright#27424

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Extra attention is needed question Further information is requested
Projects
None yet
Development

No branches or pull requests

4 participants