Happy Monday, everyone. I hope you all are staying safe and healthy in these uncertain times. Please follow your health experts’ and departments’ competent advice and guidelines to avoid contracting COVID-19. Let’s get on with our article.
As a software architect, it is essential to know where to invest in the project to add product quality more efficiently and effectively. For a UI library, we must focus on delivering components that are well tested and that sudden changes to styles don’t impact them negatively.
Here are the types of tests I would recommend developers focus their efforts within a UI library:
- Unit Tests: If the presentation component has public interface logic, definitely test this. Make sure that pipes, helpers, services, and container components have 100% code coverage. Do not test visual styles, just logic.
- Integration Tests: I define integration tests in a UI library as tests where you are testing two or more components’ templates working together. Given that the components are rendered based on the inputs provided, the critical “happy-path” rendered elements should be confirmed working in your tests. If you are using Jest as your testing framework, then just focus on capturing the snapshots. If you are using Jasmine, then create an instance of the component with input constants and validate elements are present in the Testbed render (assuming Angular testing). Again, do not test styles or animations.
- End-to-end Tests: These tests make sure that different frontend components modules work well together or individually, with the backend systems. Since our focus is on a UI library, we will not care about the backend. And if you are using Storybook.js to document your finished component modules and styles, you can run your end-to-end test on the framework. End-to-end testing is not as important in a UI library, but it can help kickstart the next type of testing that is super important…
- Visual Tests: This is where a sound UI library receives the most attention. This automated suite of tests will instantiate the entire component list in some temporary container, take a screenshot, and then compare that screenshot with a previously approved baseline. If differences are identified, then the test is flagged as “failed.” This gives you a clear visual snapshot of your entire library. It is also the most valuable type of test for a UI library. Custom or cloud solutions exist to test visual UI differences.
- Manual Tests: These should only be reserved for extreme edge cases or where visual UI tests return a “failed” test.
I hope this helps you focus your testing efforts when developing a UI library. If you have any questions or feedback, please don’t hesitate to reach out.
Best,
Guillermo
