Here we give some hints on testing AG Grid as part of your application.
End to End (e2e) Testing
We recommend using e2e tests to validate AG Grid as part of your application.
It is recommended to use e2e tests to validate AG Grid as part of your application. There are a number of tools available to help with this, such as Playwright, Cypress or Selenium.
e2e tests are recommended so that AG Grid is run inside a real browser. Fake browser environments (such as jsdom) can be used for simple unit testing cases, but their limitations can lead to confusing test results.
A few examples of how to use Playwright with AG Grid can be found in this GitHub Repo.
jsdom Limitations
Test tools such as vitest, Dom Testing Library and Jest often rely on jsdom to mock the browser.
jsdom is a pure JavaScript implementation of many web standards with the goal to emulate enough of a subset of a web browser to be useful for testing. However, there are some limitations to be aware of when using jsdom.
If you are using jsdom for testing, you may encounter issues that suggest the grid is not rendering correctly. However, this is likely caused by jsdom not supporting all the features of a real browser.
The main limitations that can affect AG Grid are:
- No support for CSS layout - impacts column / row virtualisation
- No support for
innerText
property Issue #1245 - impacts some grid components
If you wish to use jsdom for your tests you may find the following polyfill useful if you encounter issues with missing content due to the use of innerText
:
// Override the innerText setter to use textContent instead within jsdom based tests
Object.defineProperty(Element.prototype, 'innerText', {
set(value) {
this.textContent = value;
},
});
Where you implement this polyfill may vary depending on your testing setup.
We will walk through how you can use testing AG Grid as part of your Vue application, using default build tools provided when using the Vue CLI utility.
Waiting for the Grid to be Initialised
Due to the asynchronous nature of AG Grid we cannot simply mount the Grid and assume it'll be ready for testing in the next step - we need to wait for the Grid to be ready before testing it.
We can do this in one of two ways - wait for the gridReady
event to be fired, or wait for the Grid API to be set.
The first requires a code change and can be tricky to hook into - the latter is unobtrusive and easier to use.
We can create a utility function that will wait for the Grid API to be set for a set amount of time/attempts:
const ensureGridApiHasBeenSet = vm => new Promise(function (resolve, reject) {
(function waitForGridReady() {
// we need to wait for the gridReady event before we can start interacting with the grid
// in this case we're looking at the api property in our App component,
// but it could be anything (ie a boolean flag)
if (vm.$data.api) {
// once our condition has been met we can start the tests
return resolve();
}
// not set - wait a bit longer
setTimeout(waitForGridReady, 10);
})();
});
We can now use this utility method before each test or in the beforeEach
to ensure the Grid is fully ready before continuing with out test:
beforeEach((done) => {
wrapper = mount(GridExample, {});
// don't start our tests until the grid is ready
// it doesn't take long for the grid to initialise, but it is some finite amount of time
// after the component is ready
ensureGridApiHasBeenSet(wrapper.vm).then(() => done());
});
Vue Testing Library
An alternative approach would be to use the Vue Testing Library to test AG Grid. This comes with built in support for handling asynchronous behaviour which you may find easier to work with.
Testing User Supplied Components
For example, let us suppose a user provides a custom Editor Component and wants to test this within the context of the Grid.
// Editor Component - Editor.vue
<template>
<input v-model="value" type="number" style="width: 100%">
</template>
<script>
export default {
name: 'Editor',
data() {
return {
value: null
}
},
beforeMount() {
this.value = this.params.value;
},
methods: {
getValue() {
return this.value;
},
// for testing
setValue(newValue) {
this.value = newValue;
},
isCancelBeforeStart() {
return false;
},
isCancelAfterEnd() {
return false;
}
}
}
</script>
<template>
<ag-grid-vue style="width: 500px; height: 500px;"
@grid-ready="onGridReady"
:columnDefs="columnDefs"
:rowData="rowData">
</ag-grid-vue>
</template>
<script>
import {AgGridVue} from "ag-grid-vue3";
import Editor from './Editor.vue';
export default {
name: 'App',
data() {
return {
columnDefs: null,
rowData: null,
api: null
}
},
components: {
AgGridVue,
Editor
},
beforeMount() {
this.columnDefs = [
{field: 'make'},
{
field: 'price',
editable: true,
cellEditor: 'Editor'
}
];
this.rowData = [
{make: 'Toyota', price: '35000'},
];
},
methods: {
onGridReady(params) {
this.api = params.api;
}
}
}
</script>
We can test the interaction between the Grid and the Editor component via the Grid API:
it('grid renders as expected', () => {
const cells = wrapper.findAll('.ag-cell-value');
expect(cells.length).toEqual(2);
expect(cells.at(0).text()).toEqual('Toyota');
expect(cells.at(1).text()).toEqual('70000');
});
it('cell should be editable and editor component usable', () => {
// wait for the api to be set before continuing
const componentInstance = wrapper.vm;
const api = componentInstance.$data.api;
// we use the API to start and stop editing - in a real e2e test we could actually
// double click on the cell etc
api.startEditingCell({
rowIndex: 0,
colKey: 'price'
});
// update the editor input
const textInput = wrapper.find('input[type="number"]');
textInput.setValue(100000);
// stop editing
api.stopEditing();
// test the resulting values in the grid (the edited cell value should have changed)
const cells = wrapper.findAll('.ag-cell-value');
expect(cells.length).toEqual(2);
expect(cells.at(0).text()).toEqual('Toyota');
expect(cells.at(1).text()).toEqual('200000');
});
We use the Grid API to initiate and end testing as we're can't readily perform double clicks in a unit testing environment (but could if doing e2e with something like Protractor for example).