Create a screenshots page that will allow us to do screenshot testing

[andybalaam]

Signed-off-by: Andy Balaam andyb@element.io

Notes: Create a screenshots page that will allow us to do screenshot testing

I am working on a change that will modify the code of some pages without any visible effect in a visual browser. (The change is to use more table elements to make the UI easier to navigate in screen readers.)

I want to be able to check that my changes do not alter the appearance at all, so I think screenshot tests would be a good way to do this. The contributing guide mentions screenshot tests, but when I talked about this to the team we figured out that none actually exist yet.

So, this change is a draft proposal of how we could start to provide consistent renders of various components. It creates a page where we can choose a component and see it rendered:

The dropdown at the top allows choosing various different components. The list of components and how to render them is defined in src/vector/screenshots.tsx

This change is intended to be combined with a related change in matrix-react-sdk which will load this page in Puppeteer, and take a screenshot of each component.

I'm posting this to ask for feedback about whether this could be a useful feature, and whether the implementation strategy I've developed looks reasonable.

Thanks!

---

This PR currently has no changelog labels, so will not be included in changelogs.

A reviewer can add one of: T-Deprecation, T-Enhancement, T-Defect, T-Task to indicate what type of change this is, or add Type: [enhancement/defect/task] to the description and I'll add them for you.

[turt2live]

This looks like a good approach for ease of use. In the future, something like storybook or similar library functionality will prove useful, but given we need to mock out a ton of application state it seems wise to go custom.

Architecturally, I think it'd be good if we broke the mocks out to their own files somewhere. Ie: a bunch of JSON files for web responses and such that we can just import in for setting up application state. In particular, the push rules taking up a large part of the TS file isn't great.

[andybalaam]

I broke each screenshot into its own file - what do you think @turt2live ?

[Palid]

This looks like a good approach for ease of use. In the future, something like storybook or similar library functionality will prove useful, but given we need to mock out a ton of application state it seems wise to go custom.

Architecturally, I think it'd be good if we broke the mocks out to their own files somewhere. Ie: a bunch of JSON files for web responses and such that we can just import in for setting up application state. In particular, the push rules taking up a large part of the TS file isn't great.

In the past I usually had a fake-server setup with things like fetch-mock or similar that was imported based on some env vars. That makes both testing and development without server a breeze, cause things will behave like you expect them to, with delays and such.

[andybalaam]

Closing in favour of #20417