fix typo's

d4vidi · d4vidi · commit 138a60503689 · 2025-03-16T10:53:48.000+02:00
diff --git a/docs/articles/how-detox-works.md b/docs/articles/how-detox-works.md
@@ -6,11 +6,11 @@ When a Detox test executes, you actually have two different parts running side b
 
 - **The mobile app itself**, usually running on a simulator/emulator. A regular native build of your app is installed and executed on the device. Your app is usually built once before the tests start running.
 
-- **The test suite**, running on Node.js, ove ra test runner like Jest. The tests are normally written in JavaScript. Because the tests are asynchronous in nature (every test line requires to access the app and wait for a response), the tests rely heavily on [`async`-`await`](https://ponyfoo.com/articles/understanding-javascript-async-await).
+- **The test suite**, running on Node.js, over a test runner like Jest. The tests are normally written in JavaScript. Because the tests are asynchronous in nature (every test line requires to access the app and wait for a response), the tests rely heavily on [`async`-`await`](https://ponyfoo.com/articles/understanding-javascript-async-await).
 
 The two parts are usually running in separate processes on your machine. It is also possible to run the two parts on different machines. Communication between the two parts takes place over the network using a web socket.
 
-In practice, to make the communication more resilient, both parts are implemented as clients and communicate through a Detox server that acts as mediator. Haivng that server allows for some advantages like allowing one side to disconnect (during a simulator boot for example or app restart) without disconnecting the other side and losing its state.
+In practice, to make the communication more resilient, both parts are implemented as clients and communicate through a Detox server that acts as mediator. Having that server allows for some advantages like allowing one side to disconnect (during a simulator boot for example or app restart) without disconnecting the other side and losing its state.
 
 ## How Detox Automatically Synchronizes With Your App
 
diff --git a/docs/introduction/debugging.mdx b/docs/introduction/debugging.mdx
@@ -33,7 +33,7 @@ Debugger listening on ws://127.0.0.1:9229/3dedd03b-8896-4ab8-a0a8-1b647abb9c98
 For help, see: https://nodejs.org/en/docs/inspector
 ```
 
-Now you can attach to Detox and tap-in into it's execution process.
+Now you can attach to Detox and tap-in into its execution process.
 
 :::info
 
@@ -123,7 +123,7 @@ parameters to disable various side effects and make life easier when debugging:
  }
 ```
 
-- Using a preconfigured `session` with an autostarting server removes the legwork of copying and
+- Using a preconfigured `session` with an auto-starting server removes the legwork of copying and
 pasting values to the instrumentation runner launch arguments dialog every time before any launch
 from the IDE. Otherwise, by default when the `session` object omitted, `server` and `sessionId`
 are randomly generated for every new test session.
diff --git a/docs/introduction/partials/_debugging-attach-webstorm.mdx b/docs/introduction/partials/_debugging-attach-webstorm.mdx
@@ -18,7 +18,7 @@ Create a new debugging configuration using the default arguments (port 9229, etc
 
 ![Webstorm node debugging configuration](../../img/webstorm/node-debug-configuration.png)
 
-Attach to Detox by "debugging" the new configuration (start it using the beatle button).
+Attach to Detox by "debugging" the new configuration (start it using the beetle button).
 
 ![Webstorm start debug configuration](../../img/webstorm/run-debug-configuration.png)
 
diff --git a/docs/troubleshooting/synchronization.md b/docs/troubleshooting/synchronization.md
@@ -2,22 +2,22 @@
 
 <!-- markdownlint-configure-file { "header-increment": 0 } -->
 
-Traditionally, one of the most difficult aspects of E2E testing is synchronizing the test scenario with the app. Complex operations inside the app (like accessing servers or performing animations) often take a variable amount of time to complete; In each step, we can’t move on to the next one until they’ve completed (i.e. when the app goes idle), which in turn surfaces a challenge in continously trying to understand when the right time to do so is.
+Traditionally, one of the most difficult aspects of E2E testing is synchronizing the test scenario with the app. Complex operations inside the app (like accessing servers or performing animations) often take a variable amount of time to complete; In each step, we can’t move on to the next one until they’ve completed (i.e. when the app goes idle), which in turn surfaces a challenge in continuously trying to understand when the right time to do so is.
 
 Fortunately, Detox - which comes with a gray-box approach, cleverly performs the synchronization automatically, as explained [here](../articles/how-detox-works.md#how-detox-automatically-synchronizes-with-your-app).
 
-## Mitigating Synthronization Issues
+## Mitigating Synchronization Issues
 
 While Detox's auto-synchronization mechanism is powerful and efficient, it does come with at least one caveat: **It imposes strictness over the app's behavior.** By default, Detox will fail your tests (i.e. due to a wait-for-idle **time-out**), if, for example, following an app launch or a navigation to a new screen, timers or animations continue to run endlessly. While this could be considered an advantage (e.g. finding an animation or timer management leakage!), these type of issues may not:
 
-1. Be specifially related to the main coverage goal of your test.
+1. Be specifically related to the main coverage goal of your test.
 2. Be directly visible to or considered a significant bug by the end user.
 
 Therefore, it may be something some would want to be able to limit or completely opt-out of. With this in mind, let's review the possible ways of mitigation, aimed at either finding and fixing a bug, or allowing for it to be overlooked.
 
 ### Step 1: Understanding what's blocking your app
 
-Detox's syncrhonization debugging mechanism generates output to Detox's log which provides useful synchronizationd debugging information. We recommend that you'd start by pinpointing what the busy resources are - those that are keeping you app from going idle, based on those logs. Turn the debugging mechanism toggle on if you need to (although, it is on by default), rerun your test(s) and follow Detox's logs.
+Detox's synchronization debugging mechanism generates output to Detox's log which provides useful synchronization debugging information. We recommend that you'd start by pinpointing what the busy resources are - those that are keeping your app from going idle, based on those logs. Turn the debugging mechanism toggle on if you need to (although, it is on by default), rerun your test(s) and follow Detox's logs.
 
 :::info
 
@@ -54,7 +54,7 @@ await device.launchApp({
 
 ### Step 2: Applying the Most Suitable Solution
 
-First and foremost, as explained, an app's inability to go idle might be an indication of that some resources are _unnecessarily_ busy. Thefeore, whether it's a network request that's been left unacknowledged, or an endless loader - 
+First and foremost, as explained, an app's inability to go idle might be an indication of that some resources are _unnecessarily_ busy. Therefore, whether it's a network request that's been left unacknowledged, or an endless loader - 
 
 **The best solution is to fix the problem!:construction_worker:**
 
@@ -64,7 +64,7 @@ Sometimes the resource that's holding the app back from turning idle is a mere a
 
 ![App loader example](../img/app-loader.jpeg)
 
-The syncrhonization logs telling you that, would usually look roughly like this:
+The synchronization logs telling you that, would usually look roughly like this:
 
 ```
 09:04:20.170 detox[90417] i The app is busy with the following tasks:
@@ -85,11 +85,11 @@ The syncrhonization logs telling you that, would usually look roughly like this:
 
 <sup>(these are logs generated by Detox iOS; Detox-Android generates different yet equivalent ones)</sup>
 
-**Below are a few actual-bug scanerios where this can take place - all of which are easy to inspect, identify and fix.**
+**Below are a few actual-bug scenarios where this can take place - all of which are easy to inspect, identify and fix.**
 
-##### i. A server is being nonresponsive
+##### i. A server is being non-responsive
 
-Your app is waiting indefinitely to load all of the necessary data from the a nonresponsive server / a bad network, and therefore cannot switch to rendering the expected UI. When this is the deal, additional synchronization logs also repeatedly show some in-flight network calls:
+Your app is waiting indefinitely to load all of the necessary data from the a non-responsive server / a bad network, and therefore cannot switch to rendering the expected UI. When this is the deal, additional synchronization logs also repeatedly show some in-flight network calls:
 
 ```
 09:04:20.170 detox[90417] i The app is busy with the following tasks:
@@ -98,7 +98,7 @@ Your app is waiting indefinitely to load all of the necessary data from the a no
   - URL #2: https://unreachable-server.org/hello
 ```
 
-_This can be solved by finding out why the server is being nonresponsive or unreachable, for example - by tracking network calls into the logs, or inspecting requests on the server-ends._
+_This can be solved by finding out why the server is being non-responsive or unreachable, for example - by tracking network calls into the logs, or inspecting requests on the server-ends._
 
 ##### ii. A returned server error is not conveyed by the UI
 
@@ -122,14 +122,14 @@ Detox currently has no API's for "black listing" animations - namely, excluding
 
 **Not all synchronization issues around animations are trivial:**
 
-* The animation can be associated with an element that is rendered off-screen, such as an item in a long news feed that's been rendered beyond the screen's bound, or a loader in a screen associated with a bottom tab that hasn't been naviagated-to since the beginning of the test.
-* The animation can also be associated with elements which have been silently leaked (bug) under other UI elements. They are fully functional yet not visibile to the user. For example: A compact loader accidently showing under the app bar (android)/navigation bar (iOS).
+* The animation can be associated with an element that is rendered off-screen, such as an item in a long news feed that's been rendered beyond the screen's bound, or a loader in a screen associated with a bottom tab that hasn't been navigated-to since the beginning of the test.
+* The animation can also be associated with elements which have been silently leaked (bug) under other UI elements. They are fully functional yet not visible to the user. For example: A compact loader accidentally showing under the app bar (android)/navigation bar (iOS).
 
 These types of animations can be difficult to track down, and sometimes fix.
 
-**We are aiming to provide more advanced Detox-complementary tools that would help identify such animations more easily (follow github issue [#4734](https://github.com/wix/Detox/issues/4734)). Until we do, here are some things you can do, roughly, in order:**
+**We are aiming to provide more advanced Detox-complementary tools that would help identify such animations more easily (follow Github issue [#4734](https://github.com/wix/Detox/issues/4734)). Until we do, here are some things you can do, roughly, in order:**
 
-1. _(Most recommended) Start Detox in [debug mode](../introduction/debugging.mdx), and then run the blocked test step-by-step - either from the beginning of it, or starting a breakpoint you've set over where you think the synchronization issue starts. Step over the Detox commands until Detox gets blocked and signals for syncrhonization issues (i.e. in the logs). Then, explore the app yourself (!), physically looking for animations (e.g. by scrolling lists, navigating through tabs, and so on.
+1. _(Most recommended) Start Detox in [debug mode](../introduction/debugging.mdx), and then run the blocked test step-by-step - either from the beginning of it, or starting a breakpoint you've set over where you think the synchronization issue starts. Step over the Detox commands until Detox gets blocked and signals for synchronization issues (i.e. in the logs). Then, explore the app yourself (!), physically looking for animations (e.g. by scrolling lists, navigating through tabs, and so on.
    You might actually be able to see the animation in your own eyes, or witness Detox getting unblocked as your interactions release an otherwise endless loader._
    _Do this iteratively until the exact animating UI element can be pinpointed._
 
@@ -170,7 +170,7 @@ By default, Detox is designed to ignore JavaScript's `setInterval()` and will on
 
 If you can't find the source of the problem, or otherwise decide not to fix it (temporarily...), Detox always has the fail-safe solution of turning off automatic-synchronization altogether and waiting manually for elements.
 
-This isn’t the recommended approach as you'd be giving up Detox's syncrhonization super-powers and resort to manually defining timeouts, but hey, life is about tradeoffs. You can do this with the main [syncrhonization switching API's](../api/device.md#devicedisablesynchronization):
+This isn’t the recommended approach as you'd be giving up Detox's synchronization super-powers and resort to manually defining timeouts, but hey, life is about tradeoffs. You can do this with the main [synchronization switching API's](../api/device.md#devicedisablesynchronization):
 
 ```js
 // Disabling in mid test-run:
