Future of this library

[IanVS]

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]

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]

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]

@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]

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]

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]

@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]

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]

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

[jrolfs]

No worries :)

[GermanJablo]

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