Pie Aperture - Future vision

[JoshuaNg2332]

This discussion has been generated as a precursor to a meeting that we’ll be setting up over the next week to discuss the direction of PIE Aperture and how we want to scale this project to support our new components and create an even more thorough testing journey of our components.

The below is a quick overview of what PIE Aperture is currently doing and the kinds of questions we should be looking to cover off before the subsequent creation of tickets for this repo.

What is it currently doing?

PIE Aperture currently contains a number of web applications that serve to integrate our web components, mimicking the integration that would be carried out by our users. Currently however, these applications aren’t representative of real applications, and currently only serve to test mounted components on a page.

In order to properly test the integration of our components, we need to identify and address our gaps in test coverage, so that it doesn’t fall solely on our consumers to add coverage in their own applications.

Current responsibilities:

Mounting & Visual Testing of components
The primary purpose of Aperture is to mount all available components on a page, to ensure they render properly across Nuxt, NextJS and a vanilla application built using Vite.

Currently we use Percy Automate to run tests on actual target devices giving us great control of the version of the browser and the type of device it’s being run on. You can see a full list of tested devices / browsers here.

Future Plans

The purpose of this discussion is to outline the ideas we’d like to see in the repo going forward.

While we know we need to add a level of system testing that accurately represents the behaviour in the kinds of applications our consumers could be integrating with, we need to come together as a team to decide how this will function, and whether we need to adopt or change some of our development processes to cater for this.

Questions we need answering

What levels of testing would be covered?
A level of system testing that covers component interaction on a page is a big gap in our testing currently. While we know we need to add this functionality, we need to decide what form this should take.
For example what kind of pages/apps do we want to create to usefully test our components in?

How do we add capability for component interaction? (dummy pages etc)

Will we need to include other capabilities such as dummy API’s?

How can we ensure components are tested in Aperture before they’re merged into the PIE repo?

How can we ensure coverage across all our existing and new components?

How and when will we assess the framework versions we support?

How and when will we assess the browser versions we test?

What or how does the integration of new components look like?

I’m sure there’s lots of other questions that need answering.
Please feel free to provide your views down below, so that we have something to work with when we come together for the meeting to discuss!

[JoshuaNg2332]

Action points

• We should be using Aperture as a testing bed for continuous testing throughout the development of a new component and should encourage engineers to do so.
• We should be bringing aperture integration up as part of the AC for new components that are developed.
• We should use Aperture for spiking out new frameworks in the future.
• We should use Aperture for adding more tests in the future should a consumer find a bug.

Tickets

• Create more pages for mobile views
  Currently we have a problem with mobile screenshots on Pie Aperture where our components are being cut off in the screenshots either by the bottom of the screenshot or the cookie banner
  We need to look into creating additional pages for these components to live so that they can be rendered in view during mobile screenshots.

• Spike - Use of page objects from pie into aperture
  Identify components that would benefit from page objects. E.g modal / cookie banner.
  Identify components that would benefit from having selectors exposed.
  Agree on whether selectors should be defined in Page Object or exposed in a separate JS object / JSON file, so that consumers using alternate test frameworks can leverage them.

• Spike - Understand how Snacks testing repo works, how its structured and how we could use that information to have aperture set up similarly.

Tickets to be created

• Spike - Performance testing via speedcurve - wait to have a session with Fernando.
  We want to incorporate some performance testing of our components into pie-aperture.
  As part of this spike, we want to look into the integration of speedcurve and how it can be integrated into the repo.
  Fernando has mentioned that he has some experience with this topic so it might be worth reaching out to him.

• Spike - Implementation of enforced testing on aperture
  This spike is to underline what needs to be done to make testing on aperture an enforced step within our development lifecycle.
  Potentially one solution to this would be to add a new column in Jira to make sure new components are integrated correctly.