menu

Testing Library

Simple and complete DOM testing utilities that encourage good testing practices.

Channels
Chat
view-forward
# All channels
view-forward
# General
view-forward
# General Help
view-forward
# Angular Help
view-forward
# Cypress Help
view-forward
# DOM Help
view-forward
# React Help
view-forward
# Svelte Help
view-forward
# TestCafe Help
view-forward
# Vue Help
view-forward
Team

Looking for thoughts on testing table structure

January 20, 2020 at 10:53pm

Looking for thoughts on testing table structure

January 20, 2020 at 10:53pm
Our app is largely built around tables and their structure. Users need to be able to look at row & column labels and decide where to enter specific data points.
Thus far we've largely made our assertions on the fact that data shows up in the table at all. Lately, however, it has become more important to display the row and column headers themselves properly as breaking them can be very confusing to users. e.g., our thead often has multiple rows containing variable col/rowspans.
I was wondering if anyone has worked with similar and had some input on how to go about testing the general shape of tables/headers without pinning the implementation details.

January 21, 2020 at 1:46am
i havent tested tables, but i would looking into getByRole / getAllByRole and within https://testing-library.com/docs/dom-testing-library/api-queries
const table = getByRole("table")
const [columnNames, ...rows] = within(table).getAllByRole("rowgroup")
within(columnNames).getByText("id")
within(columnNames).getByText("firstName")
within(columnNames).getByText("lastName")
...
hope that helps
  • reply
  • like

January 21, 2020 at 5:11pm
so that will definitely do the trick for capturing all the pieces. the piece i'm not sure how to verify without just pinning the implementation is the visual layout of the headers. i've attached an example of a header we might use. appreciate the help!
  • reply
  • like
What do you want the tests to prove?
  • reply
  • like

January 22, 2020 at 3:36pm
i would like to have the confidence to ship changes to production without having to open up the browser to know that the table looks the same. the hard part, though, is doing it in a way that doesn't just say that all the dom elements are the same (e.g., jest snapshot). that would work, but would be brittle. given how thead is built, doing this gets a little tricky, which was why i thought i'd see if folks have any ideas.
  • reply
  • like
I meant specifically, what statements should be true about the component for it to be considered "not broken"? I find those to be a valuable tests.
  • reply
  • like
If you want to prove that thead comes before tbody, there's a test for that.
  • reply
  • like
my head goes to things like verifying that the first row spans the entire width or the first row is as wide as the number of leaf nodes under it. that sort of thing. but that feels too brittle.
  • reply
  • like
the way i started is that the number of columns (by adding the colspan for a given row) equate to the expected number and the number of rows (by adding rowspan for a given column) equate to the expected number to verify at least the outside "shape" of thead. still feels wrong, but gives us a little more confidence than nothing
Edited
  • reply
  • like
honestly a visual picture and it's deviation over time would be nice in this case, but can be brittle and expensive
  • reply
  • like
the more i think about it, if i had to call out an actual "this is completely broke" it would mean that the column is not matching up with the correct data in tbody and thus people are entering the wrong data. everything else (like thead not being laid out perfectly) just "looks" unprofessional if you know what i mean. hm...
  • reply
  • like

January 26, 2020 at 7:54pm
Example of "this is completely broken" would be:
  • "Total from Prior Year" falling under thead of "Current Year" Right?
Are you testing as one composite table? Or as components?
Without seeing markup I would try to split int to components / scenarios:
  • "unit level"- Gross Restricted needs to be as small / large as number passed in as prop or calculated based on cells below
  • "unit level" - Current thead needs to render above with width the sum of child cells
  • "unit level" - "Total from Prior Year" renters in 2x width and 2x height
  • "integration level" - "Gross Restricted" renders above and is width of "current year" + "2x2" + "2x2"
Edited
  • reply
  • like
Last place I was at that did extensive work with tables we often debated table vs div.
We found many that argued divs work better as react components but at the cost of semantic meaning and therefor a bit of accessibility.
or others have thoughts on this?
  • reply
  • like

January 28, 2020 at 6:46am
i like where your head is at. testing X is 2x as wide as Y and is directly below it, etc. that's pretty much what we've landed on as our best current solution. you do still pin a fair bit of the implementation, but in this case we thought it was a descent tradeoff.
  • reply
  • like