Add getById method to render exports

[kristianmandrup]

Describe the feature you'd like:

For many apps the labels of elements are subject to the most potential change and volatility.
In many cases makes much more sense to reference by id f.ex when developing i18n apps.

Suggested implementation:

getByTestId a shortcut to container.querySelector([data-testid="${yourId}"])

Simply add getById a shortcut to container.querySelector([id="${yourId}"])

Teachability, Documentation, Adoption, Migration Strategy:

Provide whatever docs to recommend it in some cases while not in others. I generally disagree with using text labels to reference HTML items as they are the most volatile in any app so it defeats the purpose IMO (+20 years web dev experience). But whatever rocks your boat.

Cheers.

[Gpx]

Hi @kristianmandrup, I'm curious why you say the text is volatile. Depending on which library you use to handle i18n you can have default text in your tests so that it doesn't change. An alternative could be to import your translations in the test file and use them to access your elements.

[kristianmandrup]

Yes, of course I thought about that, but then that would require the i18n setup before starting to test.
You quickly get "locked in" using the text based approach IMO.

Adding my own API wrappers to better suit my needs. No worries ;)

const apiFor = (container) => {
  const elementBy = ({
    parent,
    tag,
    id,
    testId,
    name,
    type
  }) => {
    const sel = (name, value) => {
      return value && `[${name}="${value}"]`
    }

    let elem = sel('id', id) || sel('name', name) || sel('data-testid', testId)
    const typeSel = type
      ? `type=${type}`
      : undefined
    let attrSel = `[${elem}]`;
    attrSel = typeSel
      ? `${attrSel}[${typeSel}]`
      : attrSel
    const selector = tag
      ? `${tag}${attrSel}`
      : attrSel;
    const fullSelector = parent
      ? `${parent} ${selector}`
      : selector;
    return container.querySelector(fullSelector)
  }

  const api = {
    elementBy
  }

  api.submit = ({parent, id, name, testId}) => {
    const submitButton = api.elementBy({
      parent,
      id,
      name,
      testId,
      tag: 'button',
      type: 'submit'
    })
    fireEvent.click(submitButton)
  }
  api.change = (id, value) => {
    const field = api.byId(id)
    change(field, {
      name: id,
      value
    })
  }
  return api
}

Cheers!

[kristianmandrup]

Started creating an extension library here. Designed for now, specifically for testing forms and fields...

[Gpx]

To be clear, I'm not the owner of the project. I was trying to understand what your problem is. You should keep the issue open if you think it would be a beneficial feature to add

[kristianmandrup]

All of matter of dev style and philosophy I guess. I think the way most devs develop apps these days is still pretty much in the "iron age".

A core philosophy of this extension library is to better allow accessing elements by id or name as they are way less volatile reference markers.

Personally I like to use generators to generate most of my application artifacts from various schemas. Hence I don't know or care what labels will go in. This means that the core philosophy of "testing by usage" doesn't really suit my application development style, as I don't care about what the user sees at the end... until the end!

I tend to focus first on infrastructure and leave the UI concerns including labels/text to the final stage of development (ie. "skinning"). Hence methods such as getByText or getByLabel are pretty useless to me, except perhaps for E2E testing at the end. Sure, you could somehow reference the same labels being injected, but only if the injection mechanism is "fixed" and not subject to much change either.

I like to inject texts, labels, UI framework, theming etc. much later in the dev process and maintain flexibility with regards to i18n etc.

[kentcdodds]

This means that the core philosophy of "testing by usage" doesn't really suit my application development style

I think that means this library doesn't really suit your application development style either. Your style seems at odds with this library, it's philosophy, and it's utilities.

I'd recommend you create your own render method utility with the queries you like and go with that. You can actually pass custom queries as an argument to the render method so it could be built on top of react-testing-library if you want.

In any case, this is not something we'll be adding to the library. Good luck!

[kristianmandrup]

Agreed. I think the library is fine as is. I just have a different core dev philosophy, which means I need a few extra utility methods. I'm now working on my own extension library. "Gotta keep em separated..."

[ivan-kleshnin]

I think getById/getByClassName could be useful with debug(getById(...)) to suppress say header and footer tags from cluttering the render. What I have to do now is:

<div className="page-content" data-testid="page-content">

– where ids just duplicate class names for each page type 😞

[kentcdodds]

You can use container which is a DOM node. You can use regular DOM APIs on that.

[pelotom]

You can use container which is a DOM node. You can use regular DOM APIs on that.

Yes, but that doesn't give you the nice features of the getBy* methods:

• They return exactly one result
• They throw an error if they can't find anything that matches

Personally I would love to see getById, getByClassName and getByQuerySelector added to this library! I don't really see the downside.

[kentcdodds]

I don't really see the downside.

The downside is that people start using those features instead of the queries that they should be using instead. One of the things that makes react-testing-library so great is in what it makes more difficult. Think of it like dangerouslySetInnerHTML. Generally you should avoid it, but sometimes you need to. It's important that it's possible (as an escape hatch), but the fact that it's difficult/awkward is a feature.

This is something that I don't think you will be able to convince me otherwise. Sorry.

[pelotom]

Can I just ask, why is using getByTestId any more valid under your philosophy than getByClassName? Both are “internal” attributes that the user has no perception of. The salient difference for me is that CSS classes often already exist, so you may not need to further instrument your component in order to test it.

[kentcdodds]

It's not much better. Using test ids is not recommended but it's an escape hatch to help you avoid worse selectors. Sometimes the given queries just aren't enough. Here's why a test id is better than class names it the id attribute: https://blog.kentcdodds.com/making-your-ui-tests-resilient-to-change-d37a6ee37269

[kristianmandrup]

The owner of any open source library can make his own rules and choices. If you don't like it, I guess you have to create your own extension to suit your needs and others who share that preference. Personally I also disagree with the specific choices and arguments to keep these restrictions, but I also respect it.

I've created an extension library with such extensions that you can help contribute to and improve or you can make your own.

We all have different opinions and styles etc. Not an "exact science". You can always create your own wrappers and DSL. Cheers.