@bliss-design-system/test-utils

Test Utils

• Installation
• Usage
• Contributing
  • Reporting a bug
• Troubleshooting

📦 Installation

To get access to the test utils in your app (unless it has already been installed) you can run the following command.

yarn add -D @bliss-design-system/test-utils

🏎 Usage

Each of the utilities that are provided as part of this library are described below. They address various needs for testing Bliss components in different testing scenarios.

mockBlissIcons

Our icons are currently built by creating an SVG sprite and working with the use attritube to pull the specific icon you need into a given use of the <bliss-icon> component. When using debuggers, specifically @testing-library's screen.debug() the full sprite sheet is rendered in apps making it difficult to quickly scan for the relevant piece of the debug output since it is pushed down by the sprite code.

To address the above issue we have provided a mock function which can be added as part of a setup phase for tests to mock a simplified version of the icon sprite which will prevent errors occurring in components referencing icons as well as greatly reduce the size of the sprite output to keep things focused on the relevant code you need to find when debugging.

Reduce sprite output

// setupAfterEnv.ts
mockBlissIcons('test-icon');

Testing for specific icon(s)

// YourComponent.test.ts
mockBlissIcons('info', 'action-dotted');

Shadow DOM traversal in @testing-library

A core aspect of Web Components (which is the technology powering all of the components found in @bliss-design-system/components) is the use of the Shadow DOM. The preferred testing approach used in in the Bryter application is @testing-library which currently doesn't traverse the Shadow DOM when using its many queries found on screen. We have added some prototypical functions to the technology which powers @testing-library to allow those queries to traverse the Shadow DOM.

To get this to work you need to import screen from @bliss-design-system/test-utils. It will work the same way as before and will have no effect on existing tests but in cases where Bliss Components are being used, those elements will also be queryable.

Our suggestion for implementing this alongside an existing use of @testing-library and avoiding confusion around "which screen is being imported" is to do the following:

shared-testing-goodness.ts

export * from '@testing-library';
export { screen } from '@bliss-design-system/test-utils';

Component.test.ts

import { screen, fireEvent, cleanup } from 'path/to/shared-testing-goodness';

// ... your tests

🫕 Contributing

If you'd like to contribute, please open an issue with your suggested change.

This issue will automatically be added to the Bliss Proposal Board. Once that is accepted, either the Bliss team will work on it or you can make changes locally by following the instructions and conventions in the individual package READMEs.

Reporting a bug

Notice something off? Please open an issue using our Bug Report template and fill in as many details as possible.

🙃 Troubleshooting

We'll fill this section out as we go and as issues are raised. But if you haven't found what you're looking for, get in touch via [e-mail] or via the #bliss_support Slack channel ✨.