Testing AdapTable
Summary
- AdapTable is fully testable and is framework- and runner-agnostic
- The recommended starting point is the AdapTable React Vitest Template
- Tests typically interact with AdapTable through the Adaptable API once the Adaptable Ready Event has fired
- This page covers the essentials; we are working on a fuller guide with worked examples for each test runner and framework wrapper
- If you have a specific testing question in the meantime, please contact us
Choosing a Test Runner
AdapTable is a standard JavaScript / TypeScript library and works with every mainstream test runner
There is no AdapTable-specific test framework — pick whatever your application already uses.
The runners and tools known to work well include:
| Runner | Notes |
|---|---|
| Vitest | Fast and modern, drop-in compatible with the Jest API; the runner used in our public React testing template |
| Jest | Widely used; works equally well for unit and integration tests against the Adaptable API |
| Playwright | Recommended for end-to-end tests where you want to drive AdapTable through the actual browser UI; this is what we use internally |
| Testing Library | Pairs cleanly with Vitest or Jest when rendering AdapTable inside a component test |
Hint
- Unit-style tests that drive AdapTable using Adaptable API are the fastest, most reliable and easiest to maintain
- Reach for end-to-end browser tests only when you specifically need to exercise the UI surface
Writing Tests Against AdapTable
A few practical things to know when authoring tests:
- Adaptable initialises asynchronously.
Adaptable.init(vanilla) and the framework wrappers all expose AdapTable through the Adaptable Ready Event. Wait for this event in your test setup before asserting on grid state or invoking API methods. - The Adaptable API is the primary test surface. Anything a user can do in the UI can be done programmatically through the API — applying Filters, switching Layouts, running Exports, editing cells, etc. — which makes assertions concise and avoids brittle DOM selectors.
- Stub State Persistence. In tests you almost always want
stateOptions.persistStateandstateOptions.loadStateto be no-ops (or return a fixed test fixture), so that tests are deterministic and isolated from any real backend. - Provide a deterministic
adaptableId. Different tests should use different IDs (or fully isolated state) to avoid cross-test pollution if you share a persistence layer. - Subscribe to the Adaptable State Changed Event when you need to assert that an action produced the expected state change without having to poll.
Example
The AdapTable React Vitest Template is a complete, runnable repository that shows:
- a minimal React + AG Grid + AdapTable setup
- a Vitest configuration that handles AdapTable's async initialisation
- example tests that wait for Adaptable Ready and then assert against the Adaptable API
Fork it as a starting point for your own test suite.