Tips for working with ag-grid
I'm starting to write tests for a new feature that uses ag-grid. If anyone has done this and has learned lessons the hard way, I'd appreciate tips so I don't make the same mistakes. I'm new to both ag-grid and Playwright; I've worked with custom table implementations and Selenium in the past.
My primary concern with ag-grid is that it loads and unloads cells as you scroll around the table. This makes finding cells in a test complex as you can't use a simple locator with row and column indexes unless you know with absolute certainty that the rows and columns are in the viewport at those exact positions. In practice, this means a small table that always fits in the viewport and no scrolling. For larger tables I've been getting around entering data with scrolling using tab navigation but I do need to verify values in the cells later in the test. The load/unload means that I can't get all cells as an array then use a list assertion because not all cells will be present. Playwright can't tell us how many cells are displayed, so I can't break this into chunks.
I'm currently thinking of using a hotkey to navigate to the first column with a value, then tab to each cell and check the value. That's inefficient, but might work. Said hotkey is not yet implemented so I can't test it.
Does anyone have a better approach?
This thread is trying to answer question "What are some effective strategies for testing a new feature using ag-grid and Playwright?"
@mahendra1188 I came up with the following.
To get specific cells that are loaded I wrote this helper method. I don’t love using xpath but it worked best for me. I'd prefer getByRole but it's not working reliably for me. Adding 1 to row and column indices allows us to exclude the column header row and left-pinned cells, which is just a preference.
getCellByAriaCoordinates(rowIndex: number, columnIndex: number) {
const xpath = `//*[@aria-rowindex='${rowIndex + 1}']//*[@aria-colindex='${columnIndex + 1}']`;
return this.page.locator(xpath);
}To work around load/unload when verifying cell values I resorted to this:
- Click the top-left displayed cell (not including column header row).
- Use
this.page.keyboard.press('ControlOrMeta+ArrowUp')to go to the first row in the data table. - If you don't have any pinned columns on the left, you'll also need
this.page.keyboard.press('ControlOrMeta+ArrowLeft') - Navigate to where you need to go using arrows and tab/shift-tab. Not great, but it works. I have a few specific use cases such as navigating to a specific text value in a pinned column that I'll need to implement eventually.
To verify data in the table when not all cells are loaded I use the above method to navigate to the "start" of the table, then use tab to navigate to each cell and verify the value. I store the expected values in a json file, which is convenient as Typescript types them so you can import as objects. This method works well for my app specifically because cell values are loaded asynchronously. I have an option to use soft assertions or fail on the first bad value. It's surprisingly faster than I expected.
Filtering can help but doesn't work in mine as it changes summed/rollup values in the table display. I've had to accept navigating around as above.
I've run into issues with multi-select not working correctly. I'm not sure if it's an ag-grid issue or specific to our implementation of it. One issue is that multi-select stops working: shift-click selects a single cell instead of a block. The second is that clicking a single cell does not clear an existing selection block. This happens infrequently.
Snooping around at the ag-grid demos... Hmm good reccomendations by some people, but looks more like all developers or framework creators. I get th feeling they didn't write the grid for accessibility in mind. And for the most part everything is a <div>... Great perf and more often dev centric and nothing else... My question would be more about how if possible one may put in data-test-id for key rows in their grid. If possible not so bad, but honestly from what im seeing it will be an accessibility nightmare for any screen readers for example...
Also where the xpath was used, i would suggest doing something like:
let xCount = locator.coun();
for( int idx=0; idx<xCount; idx++)
// use nth(idx) vs the xpath...even better get the document if it really is xml and process it yourself in a dom and pull out/access the data. I had a grid once with 500 rows. Going through the UI it took 20 -> 30 seconds, parsing the xml fragment was 1->2 seconds
The accessibility side is interesting. It can be fairly accessible to screenreaders, but it comes at the cost of losing some of the performance enhancements. I've tested with VoiceOver and the row/column announcing is correct (took a few tweaks on our side to do things right) at least. I haven't gone through a lot of screen reader testing yet as we're still making a lot of changes.
Rayrun is a community for QA engineers. I am constantly looking for new ways to add value to people learning Playwright and other browser automation frameworks. If you have feedback, email [email protected].