Frontend Architecture for Design Systems

Part IV. The Testing Pillar

As frontend architects, one of our greatest roles is to oversee the development of the website and design system, but anyone who has been in a project of significant scope knows that it is impossible for a single person to oversee every aspect of a project. With team members numbering in the dozens, weekly commits in the hundreds, and lines of code in the thousands, it is beyond reason to think that a single person can evaluate the impact of every single piece of code entering the system. Yet this level of evaluation is exactly what we need to be doing.

New code can introduce bugs or regressions in many different ways. Some regressions will affect the outcome of system computation, resulting in incorrect product prices, while others affect the ability of a user to successfully check out using the site shopping cart. Other regressions are visual, and while the user can still technically complete the task, the experience is made difficult because of a broken or inconsistent user interface. Lastly, even if the user interface is complete and the shopping cart functionality is working properly, the performance of the site might still render the checkout process virtually impossible on given devices or from certain geographic regions. These different types of regression stem from very different parts of your codebase, but they all have a similar impact: loss of sales. Fortunately, each of them has a very similar solution: testing!

While we as architects cannot ...