40 ‐ About tests

We managed to implement a big bunch of tests for our library. In fact, because in the future OUDS will be added in every Orange apps, we want to be sure our library won't bring regressions and issues. Because raw, semantic and components tokens are mainly generated through the tokenator, parsing a JSON file, generated by Figma, we fear to get bugs and issues because of one of these three painpoints. Having tests will make us more confident and prevent to ship bad tokens.

Unit tests of raw tokens

Raw tokens can have their values updated. Thus it is not relevant to make assertions on their values in most of cases. However, we can tests other things: their internal relationships and some rules. For example, for colors raw tokens, we assume for a group of colors they will be one-by-one lighter and lighter. For sizes, we assume one-by-one their values will be bigger and bigger. We can also check some rules defined in Figma, like 4x factor so as to be sure any values is a factor of 4. And also make assertions on range of values. In addition some raw tokens have values which must not be changed (like font weights), because a mapping is done on them ; in this type of cases we test the values.

Feel free to have a look on the unit test classes to learn the rules we assert.

Unit tests of semantic tokens

With the same logic applied to raw tokens tests, it is not relevant to test the values of the semantic tokens which can change. However, because the key feature of the library is to define themes, by overriding the values with subthemes, we have to be sure any semantic token can be overriden, that is the reason we test this property. For each semantic token we test if a theme can override it.

UI tests with screenshots

We have also unit tests fo the rendering of the components and the semantic tokens. Because we provide a library exposing a design system, we must be sure the rendering and look-and-feel of the components do not have any regressions. Thus we define unit tests making screen shots previews of components using tokens. These UI tests are based on the demo app and the awesome swift-snapshot-testing library. The tests cases creates SwiftUI Views, render them and save them as PNG images, and makes comparisons. It will help us to see wether or not semantic tokens have changed, and if components are still the same or not. The bad point is that it produces thousands of images references making the repository wiehgt bigger and bigger. But in the future the demo app will be moved in internal repository so as to make us able to test brand theme without exposing assets. Note also the UI tests fail sometimes on GitHub Action CI/CD, maybe because of ARM64 architecture. They should be run locally.

Other unit tests

Of course, we implement unit tests for other objects used inside the library.