diff --git a/website/versioned_docs/version-20.x/guide/launch-args.md b/website/versioned_docs/version-20.x/guide/launch-args.md index a8e192c907..4cb2dbc2ec 100644 --- a/website/versioned_docs/version-20.x/guide/launch-args.md +++ b/website/versioned_docs/version-20.x/guide/launch-args.md @@ -41,5 +41,5 @@ Examples: Our official recommendation for getting the arguments inside the app is by integrating the [react-native-launch-arguments](https://github.com/iamolegga/react-native-launch-arguments) project, which provides that seamlessly. For those who are interested, here are the underlying details: -- On iOS, the specified launch arguments are passed as the process launch arguments and available through normal means, such as accesing `[[NSProcessInfo processInfo] arguments]`. +- On iOS, the specified launch arguments are passed as the process launch arguments and available through normal means, such as accessing `[[NSProcessInfo processInfo] arguments]`. - On Android, the launch arguments are set as bundle-extra’s into the activity’s intent. They are therefore accessible on the native side via the current activity as: `currentActivity.getIntent().getBundleExtra("launchArgs")`. diff --git a/website/versioned_docs/version-20.x/guide/test-id.md b/website/versioned_docs/version-20.x/guide/test-id.md index c27ee99ac0..756633ce09 100644 --- a/website/versioned_docs/version-20.x/guide/test-id.md +++ b/website/versioned_docs/version-20.x/guide/test-id.md @@ -8,7 +8,7 @@ This guide was written primarily for React Native apps, but it can be generalize While [view-element matching](../api/matchers.md) can be done in numerous ways, it is always the best idea to match based on something unique and decoupled, as it ensures that the test code is clear, stable and sustainable over time. -We recommend assigning unique test ID's to the elements you're aiming to interact with in your tests, and prefering matching based on those rather than on anything else. Test ID's are the least likely to change over time (compared with raw text, for example), and are locale-agnostic. Furthermore, utilizing unique test ID's across the app not only simplifies the identification and interaction with specific elements but also enhances code navigability, making it easier to locate elements when traversing the codebase. +We recommend assigning unique test ID's to the elements you're aiming to interact with in your tests, and preferring matching based on those rather than on anything else. Test ID's are the least likely to change over time (compared with raw text, for example), and are locale-agnostic. Furthermore, utilizing unique test ID's across the app not only simplifies the identification and interaction with specific elements but also enhances code navigability, making it easier to locate elements when traversing the codebase. In React Native applications, `View` components have a dedicated [test ID property](https://reactnative.dev/docs/view#testid) that can be utilized: diff --git a/website/versioned_docs/version-20.x/introduction/your-first-test.mdx b/website/versioned_docs/version-20.x/introduction/your-first-test.mdx index 93867c22aa..c5f0682322 100644 --- a/website/versioned_docs/version-20.x/introduction/your-first-test.mdx +++ b/website/versioned_docs/version-20.x/introduction/your-first-test.mdx @@ -58,7 +58,7 @@ If your app supports deep links, you can configure it to [start from a specific :::tip -It is a good idea to start every test from a fresh state, since the preceeding ones might leave your application +It is a good idea to start every test from a fresh state, since the preceding ones might leave your application in an unpredictable state if they fail. One way to do it is to launch the app as a new instance in `beforeEach` hook instead: