TLDR; Kerry McKeever explained and demonstrated his AG Grid automation plugin for Cypress, showing where to find the code and how to create custom commands for cypress.
I had the chance to sit down with Kerry McKeever and discuss his Cypress Plugin which Automates AG Grid.
Kerry wrote a blog post about the plugin shortly after releasing it as open source and you can find the plugin on github.
We recorded the discussion and demo of the plugin.
Video of Cypress Plugin in Action
Discussion
How far should you test a 3rd party component?
During the discussion with Kerry one of the important points that cropped up was how far do you go when automating a 3rd Party component?
Really you shouldn’t have to test a 3rd party component. You test your applications interaction with the 3rd party component.
If you are pulling data from a server and rendering it in a component then you control the data that is pulled from the server so that you can easily assert that the data rendered in the component is the data you pulled from the server.
Also, if you have controls outside the component which interact with the component then you automate the control outside and assert that the 3rd party component responds as you expect. e.g. AG Grid has an API for filtering and if our application used that then we would enter text in the filter input and then assert that the filter had been applied to the grid. This isn’t testing the filtering in the component, this is testing that we can trigger filtering in the component from our code.
We test the interaction between our code and the component.
How much should you automate?
The answer is ‘just far enough to help you automate paths through your application’. This means that any open source abstraction layer for automating 3rd party components will grow organically based on the use cases it is applied to.
When someone needs to automate pagination, then they will contribute code to locate the pagination controls, synchronise on them being ready, then click the various buttons.
But until someone needs it, that functionality probably won’t exist.
Sharing Abstractions
The temptation for many teams will be to create their own abstraction layers, and that works fine for unique applications. Everyone creates unique applications and they have a specific domain language to describe them.
Over generalisation would mean that tests become too low level and read as a sequence of:
- type “user” into text input with label “username”
- type “mypassword” into text input with label “password”
- click button with text “login”
But really we want abstractions like:
- login as “user” with password “mypassword”
Shared abstractions are very valuable when working with a popular 3rd party component. The domain language used will likely be similar to most teams working with the component.
Kerry is happy to receive pull requests on the component to extend the functionality and scope for automating so if you are using Cypress and working on an application with an embedded AG Grid data grid then it might be worth tyring Kerry’s plugin, and migrating any existing abstractions into the plugin to allow other people to benefit.
