Looking for thoughts on testing table structureJanuary 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
theadoften 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
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
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!
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.
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.
If you want to prove that
tbody, there's a test for that.
my head goes to things like verifying that the
first row spans the entire widthor the
first row is as wide as the number of leaf nodes under it. that sort of thing. but that feels too brittle.
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
honestly a visual picture and it's deviation over time would be nice in this case, but can be brittle and expensive
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...
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"
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.