pare down content for readability

Author: LFDanLu

packages/dev/s2-docs/pages/react-aria/testing.mdx

@@ -5,6 +5,7 @@ export default Layout;
 
 import docs from 'docs:react-aria-components';
 import testUtilDocs from 'docs:@react-aria/test-utils';
+import {InlineAlert, Heading, Content} from '@react-spectrum/s2'
 
 export const section = 'Guides';
 export const description = 'Writing tests for apps built with React Aria';
@@ -13,28 +14,12 @@ export const description = 'Writing tests for apps built with React Aria';
 
 <PageDescription>This page describes how to test an application built with React Aria. It documents the available testing utilities available for each aria pattern and how they can be used to simulate common user interactions.</PageDescription>
 
-## Introduction
-
-Running automated tests on your application helps ensure that it continues to work as expected over time.
-You can use testing tools like [React Testing Library](https://testing-library.com/docs/react-testing-library/intro) along with test runners like
-[Jest](https://jestjs.io) or [Mocha](https://mochajs.org) to test applications built with React Aria Components or hooks. These generally
-work quite well out of the box but there are a few things to consider to ensure your tests are the best they
-can be.
-
-The information below covers best practices when writing tests, and be sure to checkout our [test utils](./react-aria-test-utils) that incorporate these
-strategies under the hood, helping streamline the test writing practice for you.
-
 ## Testing semantics
 
-Many testing libraries expect you to query for elements in the DOM tree. For example, you might have a test
-that renders a login page, finds the username and password fields, and simulates filling them out and
-submitting the form.
-
 The recommended way to query for React Aria Components and their internals is by semantics. React Aria
 Components implement [ARIA patterns](https://www.w3.org/TR/wai-aria-practices-1.2/). ARIA is a W3C standard
-that specifies the semantics for many UI components. This is used to expose them to assistive technology
-such as screen readers, but can also be used in tests to operate the application programmatically. These semantics
-are much less likely to change over time, and while other DOM nodes may be added or removed, the semantics are more likely to stay stable.
+that specifies the semantics for many UI components. Unlike the DOM structure of the component, these semantics are much less likely to change over time,
+making them ideal to query for.
 
 The main attribute to look for when querying is the [role](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques).
 This attribute represents the type of element a DOM node represents, e.g. a button, list option, or tab.
@@ -55,19 +40,12 @@ let option = tree.getByRole('button');
 
 ## Test ids
 
-Querying by semantics covers many scenarios, but what if you have many buttons on a page? How do you find the specific button
-you're looking for in a test? In many cases this could be done by querying by the text in the button or an
-accessibility label associated with it, but sometimes this might change over time or may be affected by things like
-translations in different languages. In these cases, you may need a way to identify specific elements in tests, and that's
-where test ids come in.
+Querying by semantics covers many scenarios, but what if you have many buttons on a page or its text changes due to translations based on locale?
+In these cases, you may need a way to identify specific elements in tests, and that's where test ids come in.
 
 React Aria Components pass all [data attributes](https://developer.mozilla.org/en-US/docs/Learn/HTML/Howto/Use_data_attributes)
 through to their underlying DOM nodes, which allows you to use an attribute like `data-testid` to identify
-a particular instance of a component. For example, you could add test ids to the two input elements
-in a login form and use them to find the username and password fields.
-
-This example uses React Testing Library, but the idea could be applied in a similar way with other
-testing libraries.
+a particular instance of a component.
 
 ```tsx
 import {render} from '@testing-library/react';
@@ -95,25 +73,13 @@ let password = tree.getByTestId('password');
 
 ## Triggering events
 
-Most testing libraries include a way to simulate events on an element. React Aria Components rely on
-many different browser events to support different devices and platforms, so it's important to simulate
-these correctly in your tests. For example, rather than only simulating a click event, the tests should
-simulate all of the events that would occur if a real user were interacting with the component.
-
-For example, a click is really a `mousemove` and `mouseover` the target, followed
-by `mousedown`, `focus`, and `mouseup` events, and finally a `click` event. If you only simulated the `click`
-event, you would be missing all of these other preceding events that occur in real-world situations and this
-may make your test not work correctly. The implementation of the component may also change in the future to
-expect these events, making your test brittle. In addition, browsers have default behavior that occurs on
-certain events which would be missing, like focusing elements on mouse down, and toggling checkboxes on click.
+React Aria Components rely on many different browser events to support different devices and platforms, so it's important to simulate
+these correctly in your tests. For example, a click is really a `mousemove` and `mouseover` the target, followed
+by `mousedown`, `focus`, and `mouseup` events, and finally a `click` event.
 
 The best way to handle this is with the [user-event](https://github.com/testing-library/user-event) library.
 This lets you trigger high level interactions like a user would, and the library handles firing all of the individual
-events that make up that interaction. If you use this library rather than firing events manually, your tests
-will simulate real-world behavior much better and work as expected.
-
-`user-event` can handle many types of interactions, e.g. clicks, tabbing, typing, etc. This example shows how you could
-use it to render a login form and enter text in each field and click the submit button, just as a real user would.
+events that make up that interaction.
 
 ```tsx
 import {render} from '@testing-library/react';
@@ -140,16 +106,17 @@ TODO can't place this next to the header here
 <VersionBadge version="beta" />
 
 [@react-aria/test-utils](https://www.npmjs.com/package/@react-aria/test-utils) is a set of testing utilities that aims to make writing unit tests easier for consumers of React Aria
-or for users who have built their own components following the respective ARIA pattern specification. By using the ARIA specification for any given component pattern as a source of truth,
-we can make assumptions about the existence of various aria attributes in a component. This allows us to navigate the component's DOM structure, simulate common interactions, and verify the
-the resulting state of the component.
+or for users who have built their own components following the respective ARIA pattern specification.
 
 ### Installation
 
 <InstallCommand pkg="@react-aria/test-utils" flags="--dev" />
 
-Please note that this library uses [@testing-library/react@16](https://www.npmjs.com/package/@testing-library/react) and [@testing-library/user-event@14](https://www.npmjs.com/package/@testing-library/user-event). This means that you need
-to be on React 18+ in order for these utilities to work.
+<InlineAlert variant="notice">
+  <Heading>Requirements</Heading>
+  <Content>Please note that this library uses [@testing-library/react@16](https://www.npmjs.com/package/@testing-library/react) and [@testing-library/user-event@14](https://www.npmjs.com/package/@testing-library/user-event). This means that you need to be on React 18+ in order for these utilities to work.</Content>
+</InlineAlert>
+
 
 ### Setup