Testing AdapTable

Summary

  • 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:

RunnerNotes
VitestFast and modern, drop-in compatible with the Jest API; the runner used in our public React testing template
JestWidely used; works equally well for unit and integration tests against the Adaptable API
PlaywrightRecommended for end-to-end tests where you want to drive AdapTable through the actual browser UI; this is what we use internally
Testing LibraryPairs 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.persistState and stateOptions.loadState to 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.