chore: fix typos (#29)

Author: aaronmcadam

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.

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_:
 
 <callout-success class="important">A test must fail if, and only if, the intention behind the system is not met.</callout-success>
 

exercises/02.test-structure/04.solution.hooks/README.mdx

@@ -10,7 +10,7 @@ Then, I implement the `beforeAll()` function, which invokes the given `callback`
 
 <CodeFile file="setup.ts" range="32-34" highlight="33" />
 
-<callout-warning>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.</callout-warning>
+<callout-warning>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.</callout-warning>
 
 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.
 

exercises/02.test-structure/FINISHED.mdx

@@ -2,4 +2,4 @@
 
 <EpicVideo url="https://www.epicweb.dev/workshops/testing-fundamentals/test-structure/test-structure-outro" />
 
-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.

exercises/03.async/02.solution.rejections/README.mdx

@@ -36,7 +36,7 @@ rejects: {
 }
 ```
 
-<callout-warning>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.</callout-warning>
+<callout-warning>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.</callout-warning>
 
 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: