Testing

Unit Tests

We recommend writing unit tests of your own methods/functions/components rather than testing the ActiveUI plugin/component itself. For example, if you define a plugin like this:

createActiveUI({
  plugins: {
    yourPluginType: [
      {
        createProperties: (parameters) => ({
          countFoo: yourCountFunction,
          renderBar: YourComponent,
        }),
      },
    ],
  },
});

Instead of trying to instantiate the plugin and then test it, we recommend writing separate tests for yourCountFunction and YourComponent.

  • You could test yourCountFunction with a test runner and assertion library (e.g. Jest).
  • You could test YourComponent by also using some React specific utilities (e.g. React Testing Library).

End-to-end Tests

Writing end-to-end tests for a web app generally involves:

  • Serving a production build of your app (this could be on CI or in production).
  • Using a selector to query the DOM for an element before interacting with it.

To make your end-to-end tests more resilient, ActiveUI can render data-testids to use in selectors. You can enable this by making sure the following code is run before your app is rendered:

window.__UNSTABLE_DATA_TEST_IDS_ENABLED__ = true;

This will tell ActiveUI to render data-testids in some places.

As it says in the name, you should not expect these data-testids to be stable across releases. If they do change when upgrading (causing your end-to-end tests to fail) then you will need to rewrite some of your selectors.

Once data-testids are enabled they will look like this in the DOM:

<span data-testid="ActiveUI:Tile:Filter:Time/HistoricalDates"> ... </span>

To make your tests using ActiveUI more robust, we recommend that you use a combination of these strategies:

  • Create a test page that renders only the component under test, then run your end-to-end test on this page. For example, instead of loading an ActiveUI dashboard that contains a custom widget, render just your custom widget directly on the test page.

  • Put data-testids or classes in your components that you can use as selectors. Try to select the data-testids and classes within your components,not ones on elements from ActiveUI.

  • If you must interact with the ActiveUI elements within your tests, you can query for text instead of relying on data-testids. For example, search for a text node with the name of a bookmark, then simulate a click on its parent element.

    If the item with the text label is not the specific element you want to interact with, traverse the DOM relative to the element you found. For example, find “the first div under the previous sibling element”. This DOM traversing will be brittle if ActiveUI elements change, but that is unavoidable with this strategy.

  • Write unit tests of your own components instead of end-to-end tests of our components. See how to write unit tests.

  • As a general rule try to focus tests on your own components instead of testing components from ActiveUI SDK.

If there is no data-testid on the element that you need to interact with and all the strategies above fail, it is always possible to directly use selectors that follow the full DOM structure of the application down to the element that needs to be tested. Such selectors might have to be updated after each ActiveUI upgrade. Try not to rely on class names for selectors, as ActiveUI uses hashes for them which can change frequently.

Notes

About Tables and Query Results

Pivot tables, tabular views, drillthroughs or any other types of tables are lazy rendered on top of being lazy loaded. This means that, introspecting the DOM structure of such tables, the DOM only contains what is being displayed to the end user. For example, if a cellset result has 10,000 rows and 300 columns, but only 25 rows and 8 columns are displayed to the screen, ActiveUI only renders those that are visible for optimization purposes.

If it is necessary to ensure a dataset result is correct for a particular query, it is recommended that you create a test against ActivePivot webservices directly: i.e. testing that given a specific MDX and set of context values, ActivePivot server returns the correct result.

← Tabular View and Pivot TablesAPI Reference →