Testing DatePicker(s) using Testing Library

[RobHannay]

I'm upgrading our date/time fields & pickers to use React Aria Component underneath, and they're much nicer to use.

The only issue is knowing how is best to input data during tests. We use Testing Library both within Jest and within Cypress.

What I've got down to is selecting each segment by spinbutton role, but that feels brittle because it doesn't account for different date formats.

    cy.findByRole('group', { name: label }).within(() => {
      cy.findByRole('spinbutton', { name: `year, ${label}` }).type(year.toString());
      cy.findByRole('spinbutton', { name: `month, ${label}` }).type(month.toString());
      cy.findByRole('spinbutton', { name: `day, ${label}` }).type(day.toString());
      cy.findByRole('spinbutton', { name: `hour, ${label}` }).type(hour.toString());
      cy.findByRole('spinbutton', { name: `minute, ${label}` }).type(minute.toString());
    });

What I'd love it some way of selecting the overall field by its label, and then passing a CalendarDateTime instance to input it.

I've tried looking in the test-utils package, but that doesn't look like it has anything to do with dates in.

What would you reocmmend in my case?

[reidbarber]

I think @LFDanLu might bight be interested in this since he has been working on aria test utils (Related: #7145)

[LFDanLu]

Thanks for letting me know about this one @reidbarber. @RobHannay I haven't quite gotten to brainstorming how best to simulate actions for a DatePicker, but my gut feeling is that we could perhaps walk through the spinbuttons and reverse engineer the expected date format, then use the provided CalendarDateTime and produce the sequence of values that would need to be typed to fill out the field. The spinbuttons have aria-valuemin/maxes that could help identify what datetime segment it covers (e.g. if it has a min max of 1 to 12 then it is the month spinbutton). Would need to see if these is feasible. I'm also not very familiar with Cypress, was there a requirement that you had to select each spinbutton via its role + label and fire a type event on it or could you instead just fire keyboard events on whatever is currently focused in the browser and let the focus auto advancing behavior handle moving to the next spin button?

However on the flip side, this could be deemed as too complex and instead perhaps the onus would be on the user to provide a suitable sequence of numbers that the test utility would type instead. I don't think it would be too much to expect from a test writer to know what expected date format should apply for a specific test case especially since I'd assume they would want to assert that a specific result should happen as a result of a specific date value being entered in. What do you think?

[RobHannay]

just fire keyboard events on whatever is currently focused in the browser

Hmm, I didn't try this but I guess the big problem with this could be the different spinbutton order depending on locale. Admittedly, we do run all of our tests in a constant locale, so not a big issue.

We would also still need to know what to focus on first, i.e. in our case the day spinbutton. We could select it by label, the same way we do in my snippet.

But my hunch around Cypress says this wouldn't work with how it types into yielded elements

know what expected date format should apply

For completeness, currently my solution does require dates to be provided in a specific format.

In Jest, I do something like

  const [year, month, day] = date.split('-');
  await userEvent.type(screen.getByRole('spinbutton', { name: `day, ${label}` }), day);
  await userEvent.type(screen.getByRole('spinbutton', { name: `month, ${label}` }), month);
  await userEvent.type(screen.getByRole('spinbutton', { name: `year, ${label}` }), year);

etc

And in Cypress we use Cucumber Expressions which kind of helps with this:

Then(
  'I set the {string} datetime field to {int}-{int}-{int} {int}:{int}',
  (label: string, year: number, month: number, day: number, hour: number, minute: number) => {
    cy.findByRole('group', { name: label }).within(() => {
      cy.findByRole('spinbutton', { name: `year, ${label}` }).type(year.toString());
      cy.findByRole('spinbutton', { name: `month, ${label}` }).type(month.toString());
      cy.findByRole('spinbutton', { name: `day, ${label}` }).type(day.toString());
      cy.findByRole('spinbutton', { name: `hour, ${label}` }).type(hour.toString());
      cy.findByRole('spinbutton', { name: `minute, ${label}` }).type(minute.toString());
    });
  },
);

But in some test cases, I'm doing date manipulation relative to the current date, then converting it into that format to make it work, which feels mucky. It would be great to be able to provide e.g. a CalendarDate object to a test util, along with either an accessible name or a group node which is the wrapper around the picker input.

[LFDanLu]

Hmm, I didn't try this but I guess the big problem with this could be the different spinbutton order depending on locale. Admittedly, we do run all of our tests in a constant locale, so not a big issue.
We would also still need to know what to focus on first, i.e. in our case the day spinbutton. We could select it by label, the same way we do in my snippet.

My only hesitation with selecting it via the label would be the locale actually since you'd need to provide the localized label then right? You may have access to that which would make it a non-issue, but I think tentatively as an alternative solution we could just select the first spinbutton within the group and try to discern what value it takes via some of its aria attributes and input the desired matching value from there.

Ideally it just feels like the inputs to the test util should be the desired date time (via a CalendarDate like you suggested perhaps), and a selector/pointer to the component wrapper which we could then query for the spin buttons within via role (again, mirroring what you suggested). Then the internals to the util would figure out what date time format the field accepts by seeing what spinbuttons fields exist, parses the provided CalendarDate appropriately to create a set of values to input into the field by matching that format, then types it in the field starting from the first spin button mimicking how a end user would type it. I think I'm basically saying what your listed above haha, lemme know if that matches up.

[RobHannay]

since you'd need to provide the localized label

Yeah you're right! Though, this tends to be our preferred method (in English) for selecting elements by their role + accessible name.

But I also agree that the test util shouldn't be opinionated about labels - it should take the DatePicker group element and do whatever it needs internally.