diff --git a/exercises/02.test-structure/01.solution.assertions/README.mdx b/exercises/02.test-structure/01.solution.assertions/README.mdx
index a721f1f..1e73a8d 100644
--- a/exercises/02.test-structure/01.solution.assertions/README.mdx
+++ b/exercises/02.test-structure/01.solution.assertions/README.mdx
@@ -12,4 +12,4 @@ Then, refactor the existing tests to use the new `expect` function.
Notice how much more human-friendly those assertions have become! Although a test is code that verifies another code, we still write them for ourselves and for our colleagues. We still write tests for humans. Preferring a more declarative style while doing so, such as our `expect` function, is one way to make sure those humans can get around faster and tackle failing tests more efficiently.
-Additionally, abstractions like `expect` help us maintain our testing suite by keeping all assetions in one place. Assertions reflect our expectations, and those will evolve and multiple as we keep testing our app. It's nice to know that whenever we want to check equality (`.toBe()`, `.toEqual()`), truthfulness (`.toBeTruthy()`), or errors (`.toThrow()`), we can always count on the same `expect()` function.
+Additionally, abstractions like `expect` help us maintain our testing suite by keeping all assertions in one place. Assertions reflect our expectations, and those will evolve and multiple as we keep testing our app. It's nice to know that whenever we want to check equality (`.toBe()`, `.toEqual()`), truthfulness (`.toBeTruthy()`), or errors (`.toThrow()`), we can always count on the same `expect()` function.
diff --git a/exercises/02.test-structure/04.problem.hooks/README.mdx b/exercises/02.test-structure/04.problem.hooks/README.mdx
index a4846bb..f91e3cd 100644
--- a/exercises/02.test-structure/04.problem.hooks/README.mdx
+++ b/exercises/02.test-structure/04.problem.hooks/README.mdx
@@ -47,7 +47,7 @@ afterAll(() => {
## The Golden Rule of Assertions
-This problem illustrates the importance of the testing setup for the quality of your tests. Our code does what it was inteded to do but the tests still fail. When that happens, you know you've got a _bad test_. Turns out, such tests don't pass _The Golden Rule of Assertions_:
+This problem illustrates the importance of the testing setup for the quality of your tests. Our code does what we intended but the tests still fail. When that happens, you know you've got a _bad test_. Turns out, such tests don't pass _The Golden Rule of Assertions_:
A test must fail if, and only if, the intention behind the system is not met.
diff --git a/exercises/02.test-structure/04.solution.hooks/README.mdx b/exercises/02.test-structure/04.solution.hooks/README.mdx
index 15227e4..40b39ab 100644
--- a/exercises/02.test-structure/04.solution.hooks/README.mdx
+++ b/exercises/02.test-structure/04.solution.hooks/README.mdx
@@ -10,7 +10,7 @@ Then, I implement the `beforeAll()` function, which invokes the given `callback`
-Here, I'm relying that the `beforeAll()` function will be called _before_ any individual tests. Actual testing frameworks usually have a runner responsible for internally orchestrating hooks and tests regardless of the invocation order.
+Here, I'm relying on the fact that the `beforeAll()` function will be called _before_ any individual tests. Actual testing frameworks usually have a runner responsible for internally orchestrating hooks and tests regardless of the invocation order.
The `afterAll` function will be a bit different. To invoke the `callback` once the tests are done, I will utilize the `beforeExit` event of a Node.js process to let me know when the test run is about to exit.
diff --git a/exercises/02.test-structure/FINISHED.mdx b/exercises/02.test-structure/FINISHED.mdx
index 7f13955..6868b8e 100644
--- a/exercises/02.test-structure/FINISHED.mdx
+++ b/exercises/02.test-structure/FINISHED.mdx
@@ -2,4 +2,4 @@
-Fhew, that was a lot but you've nailed it! :clap: Take some rest, take some notes, and see you in the next exercise.
+Phew, that was a lot but you've nailed it! :clap: Take some rest, take some notes, and see you in the next exercise.
diff --git a/exercises/03.async/02.solution.rejections/README.mdx b/exercises/03.async/02.solution.rejections/README.mdx
index aa10249..a72576b 100644
--- a/exercises/03.async/02.solution.rejections/README.mdx
+++ b/exercises/03.async/02.solution.rejections/README.mdx
@@ -36,7 +36,7 @@ rejects: {
}
```
-In the video, I made a mistake at 02:00! The handling of fasle-positive scenarios must be done via `.then(onFulfilled, onRejected)` callback, not via the `.then().catch()` chaining. See the correct implementation below, and feel free to skip to 02:28 to watch the rest of the solution.
+In the video, I made a mistake at 02:00! The handling of false-positive scenarios must be done via `.then(onFulfilled, onRejected)` callback, not via the `.then().catch()` chaining. See the correct implementation below, and feel free to skip to 02:28 to watch the rest of the solution.
To handle the unwanted cases when the `actual` promise resolves, I will replace the `.catch()` callback with a single `.then()` callback, providing it with two arguments: