[Fabric]: Performance Tests for React Native Windows

[iamAbhi-916]

Description

Performance testing framework for RNW Fabric components.
Each test measures mount, unmount, re-render and component specific test scenario times also records baselines via snapshot matching.

How to Run

cd packages/e2e-test-app-fabric
yarn perf                                              # all tests
yarn perf -- --testPathPattern=FlatList                 # single component
yarn perf:update                                       # update all baselines
yarn perf:update --testPathPattern=TouchableHighlight   # update one baseline

CLI Generator

yarn perf:create -- --name=ComponentName scaffolds a new .perf-test.tsx file with the correct structure, required props detection, and category selection.

Type of Change

• New feature (non-breaking change which adds functionality)

Why

RNW Fabric had no automated way to catch render performance regressions in core components.

Resolves #15665

What

Refer this wiki : https://github.com/microsoft/react-native-windows/wiki/Performance-tests-Fabric

Screenshots

Testing

Tested locally, mock ran as CI

Changelog

Should this change be included in the release notes: yes

Add a brief summary of the change to use in the release notes for the next release.
Added @react-native-windows/perf-testing, a component performance testing framework for RNW Fabric

Microsoft Reviewers: Open in CodeFlow

[acoates-ms]

Can we make the tests be more intensive. Perf tests that are measuring 5ms, are not likely to notice even a 10% regression in time (as 10% increase of 5ms is still 5ms with that level of accuracy).

Can we make 100x the number of components or something to try to get bigger numbers, where changes would be more noticable?

[iamAbhi-916]

Can we make the tests be more intensive. Perf tests that are measuring 5ms, are not likely to notice even a 10% regression in time (as 10% increase of 5ms is still 5ms with that level of accuracy).

Can we make 100x the number of components or something to try to get bigger numbers, where changes would be more noticable?

Initial focus was coverage breadth — getting all 14 components wired up with mount/unmount/rerender baselines and the statistical framework (Mann-Whitney, CV gate) and single-component scenarios validate correctness and catch catastrophic regressions (e.g. 0 ms → 50 ms), but you're right that they can't catch subtle ones.

Added stress tests !