Testing overview

What needs testing?

Jutro apps follow the React philosophy of composing from components. Jutro UIs are built starting with atomic components. These components are composed into pages. Pages are managed using a floorplan.

Every piece of UI is technically a component, even a page is a component. So, testing your app is synonymous with testing components.

e2e (end-to-end testing)

Typical user interactions mean using multiple components. e2e testing means testing groups of components, an entire page, or even multiple pages in an app. The tests you write "click", "complete fields", "drag-and-drop elements" and perform other actions that a user would perform.

e2e is the most robust way to verify the functionality of your app and the easiest to plan. You reflect your major user journeys in the tests and you can always be sure that the user can do what they need to do in your app.

Visual

Visual tests in Jutro rely on TestCafe. TestCafe creates a screenshot and compares it to a previous screenshot. This allows you to catch any accidental changes.

For consistency, you run the tests using specific browsers, usually in a Docker image.

Known issues

There is a known issue with testcafe using hummerhead that makes micro frontends fail to render randomly. To solve this issue, upgrade testcafe to version 3.x.x as newer versions do not use hummerhead by default. In case you need to use it, you use the --disableNativeAutomation option.

Unit

Some functionality is more theoretical than user interactions. Unit tests allow you to confirm that even very small parts of your app work as intended. When writing unit tests for Jutro apps, you test things like:

• check whether the app renders without crashing
• check if a metadata-based component has valid metadata
• check if a function that is supposed to shorten long descriptions actually returns strings of specified length and does not crash when the description is shorter than the specified length
• check is a callback is called
• check if a side effect is triggered the appropriate number of times

Accessibility

Accessibility (a11y) tests highlight issues that people may have when using your app with some form of visual, hearing, mobility, or other disability. We use jest-axe to automatically test a11y basics, but we strongly recommend that you follow up with manual testing. This is the only certain way to ensure the desired level of accessibility in your app.

Understanding the workflow

To streamline your development experience, we recommend the following workflow:

• 🧪 Write an e2e test of your functionality.
• 😊 Write unit tests to define all the small details of each individual component.
• 💻 Develop the each component to build the overall functionality until the all the tests pass.
• ♿️ Verify accessibility (this may change the look-and-feel of your app!)
• 🎨 Add visual tests to capture the intended look-and-feel of your component, group of components or page.
• 🚥 Make sure your tests run and pass in Teamcity on every pull request.