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 spend all of our time watching every single line of code being committed, we are able to set up various suites of tests to verify our application is working properly.

Here are a few things to remember when you start looking at planning test coverage for your application:

• Tests are written while the site is being built, or even before actual code is written.
• They are living code, committed with or next to the system repository. 
• All tests must pass before any code is merged into the master branch.
• Running the suite on the master branch should always return a passing response. 

This means that no code should ever be merged that breaks the system’s ability to calculate values, perform critical business actions, display the correct UI, or deliver a performant experience. So instead of trying to oversee thousands of lines of code, an architect should focus on creating a system for quality and complete test coverage.