Data test-ids: How would they be shared between a fullstack repo and a playwright repo?

Discussions
,
1

I’m trying to search for best practices of sharing data test IDs of elements from a full stack project that uses rails to a Playwright project in typescript. (Why are the in different repos? Don’t ask.)

  1. What could be a good solution to achieve this?
  2. The fullstack team writing a script that generates a JSON files on deployment and the file is then fetched by the playwright project?

The idea here is to keep in sync with changes made by the dev team.

2 Likes
2

Hey, I’m a bit confused as to the context of this question. Are you looking for a way to automatically define selectors for new page elements? Or is the problem that test-ids for the same elements are being frequently changed and need to be updated in your Playwright repo? Or something else?

3

@hananurrehman,

Big question! Sharing data for test IDs between a full-stack repo and Playwright repo can be complicated, mainly when they reside in separate repos.

Have the full-stack team generate a JSON file at deployment, containing all of the test IDs needed, which can be fetched by the Playwright project as needed. Everything remains in sync-this is the important part-because in the meanwhile, it is the full-stack developers that are making alterations to the app.

Another possibility is that the full-stack team creates a little API endpoint just for serving the test IDs so Playwright can always pull the newest version on every run. Just remember to version control the API or JSON-based data package so both ends stay in sync.

You could then experiment with environment variables at local dev and CI environments, but that might not scale with a lot of test IDs.

Whichever way you go, the whole point is to make sure the full-stack changes flow down automatically into the Playwright repo without duplicating the effort.

Hope that helped!

1 Like
4
  • data-test Ids are generally static.
  • Their property of being static make them suitable for automation.
  • If they are changing it defeats the purpose we want to achieve with it.

So whatever deployment is going test-id should remain same. If new elements getting added due to new development. We are yet to write script for it.

  • For those which are already there should not change
5

@gaurav.jaz’s comment makes sense, such a document sharing is not needed as data test IDs are not something that should change frequently.

1 Like
6

Apologies as I am going to ask backtrack question - why in the first place do we need to use data test-ids? As it suggests there are lots of elements on the page that are bound to be dynamic.

To nip the evil in the bud - can you connect with your dev teams and ensure there are less dynamics elements on the page so you might not need to use test-ids in the first place.

PS: I typed the comment and never posted :smiley:

7

Hi Aiman,

The idea behind data test IDs is to have robust locators which are unbothered by any changes. Thankfully I don’t have to deal with dynamic elements that much.

The reason why the question rose in my mind was because we are transitioning to data test ID implementation but then I realised, since these IDs are created to avoid being bothered by UI changes, there’s no real need for “sharing” them since its a one time job to implement them.

8

Do you want to test the code (unit-test or integration test mindset) or do you want to test the behaviors from an end-user view-point (e2e test mindset)?

Because if that’s the latter / second one, then data-test-ids are falling a bit short of your objective, aren’t they?

If your e2e tests breaks, then that means the dev have broken/changed a key behavior in the app. If it is intentional, that means maybe it is too early to use e2e tests, the product is not mature enough. If not intentional, then you want to catch it.

Like many things, before jumping into the “how”, I’d question the “why” :slight_smile:

1 Like