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-testid
s 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-testid
s in some places.
As it says in the name you should not expect these
data-testid
s 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-testid
s 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 some 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-testid
s orclass
es in your components that you can use as selectors. Try to select thedata-testid
s andclass
es within your components, not ones on elements from ActiveUI.If you must interact with ActiveUI elements within your tests you can query for text instead of relying on
data-testid
s. 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 components instead of testing components from ActiveUI SDK.
If there is no data-testid
on the element you need to interact with and all strategies above failed,
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 the one that are visible for optimization purpose.
If one need to ensure a dataset result is correct for a particular query, we recommend to 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.