A wise person once said...

Code that changes together should stay together

although I can't remember who it was. But that isn't important - what's important is that following this principle for test ids just got a whole lot easier!

What's your problem?

I'm a big believer in starting from a problem not a solution, so let's think about what problems can be associated with defining test ids.

Multiple teams need to know what they are - for example, QA want to write an automation test, Product want to instrument a button.
It's easy to mistpye and make mistakes
Accidental changes can break other teams work

What can we do?

The approach to test ids can follow a few pathways, but one frequent solution goes...

Just write strings in individual files
Argh but how do I get these to test
OK, we'll use a singe file of test id definitions and refer to these in each file that needs them
Oh no my split bundles just got broken, and somebody mis-spelled button. Again. Also, my test ids now live miles from the components that need them.
There must be a better way

We recently got to step 5, and thought through some ways forward that would solve all the test id woes. We ended up with...

test-ids

Original and thoughtful name aside, what does test-ids do? Well, it lets us define test ids in the files that need them, via a magic $TestId object:

<div data-testid={$TestId.Introduction} />

But transpile these to strings at build time, so there isn't any runtime cost:

<div data-testid={"Introduction"} />

It also extracts those strings into a single JSON file that can be given to other teams:

{
  "Introduction": "Introduction"
}

It's a relatively simple idea, implemented via a babel plugin, which is a little bit magic, but hopefully not tooo much.

Sound Good?

I think so, I hope you do too. Why not have a look in more detail in the GitHub repo - https://github.com/alsiola/test-ids

If you like the idea, but think we can do even better, then raise an issue, make a pull request, or send me pleasant messages on Twitter.