fix: correct typo in README regarding expected result (#32)

Author: rubenpenap

exercises/01.principles/README.mdx

@@ -50,7 +50,7 @@ Conceptually, the steps we have to test the `sum` function remain the same:
 
 1. Pick a code to test (i.e. our `sum` function);
 1. Run the code with particular arguments;
-1. Check whether the actual result equals to the expected (indended) result.
+1. Check whether the actual result equals to the expected (intended) result.
 
 Here are the same steps (abstractly) represented in JavaScript:
 

exercises/02.test-structure/01.problem.assertions/greet.ts

@@ -34,6 +34,6 @@ if (message !== 'Congrats, Sarah!') {
 // return { toBe(expected) {} }
 
 // 🐨 In the "toBe" function, compare the "actual" and the "expected"
-// values, and throw an error if they don't mtach.
+// values, and throw an error if they don't match.
 // 💰 You can throw an error like this one:
 // new Error(`Expected ${actual} to equal to ${expected}`)

exercises/02.test-structure/03.problem.test-files/greet.ts

@@ -11,8 +11,8 @@ function congratulate(name: string) {
 }
 
 // 🐨 Move the existing tests for "greet()" and "congratulate()"
-// to the newly added "greet.test.js" file. Don't forget to
-// import the "test()" and "congratulate()" functions there!
+// to the newly added "greet.test.ts" file. Don't forget to
+// import the "greet()" and "congratulate()" functions there!
 test('returns a greeting message for the given name', () => {
 	expect(greet('John')).toBe('Hello, John!')
 })
@@ -22,7 +22,7 @@ test('returns a congratulation message for the given name', () => {
 })
 
 // 🐨 Move the existing "expect()" and "test()" functions to the
-// newly added "setup.js" file.
+// newly added "setup.ts" file.
 function expect(actual: unknown) {
 	return {
 		toBe(expected: unknown) {

exercises/02.test-structure/README.mdx

@@ -8,7 +8,7 @@ Now that we have the basic test written, let's iterate on it. See, no matter wha
 1. Compare the actual result with the expected result;
 1. Throw an error if those two don't match.
 
-In other words, every test follows 📜 [a predicatable structure](https://www.epicweb.dev/anatomy-of-a-test). And that's great! It means we can open any project and go to any test and follow that structure to help us navigate around and understand things. It also helps with writing tests because it gives us this framework on how to approach testing _anything_.
+In other words, every test follows 📜 [a predictable structure](https://www.epicweb.dev/anatomy-of-a-test). And that's great! It means we can open any project and go to any test and follow that structure to help us navigate around and understand things. It also helps with writing tests because it gives us this framework on how to approach testing _anything_.
 
 ---
 

exercises/03.async/01.problem.await/README.mdx

@@ -14,7 +14,7 @@ export async function greetByResponse(response: Response) {
 So now, whenever we need to greet a fetched user, we can use this new function:
 
 ```ts nocopy nonumber
-fecth('/api/user')
+fetch('/api/user')
 	.then(response => greetByResponse(response))
 	.then(greeting => render(greeting))
 ```

exercises/03.async/03.problem.waitFor/README.mdx

@@ -2,7 +2,7 @@
 
 <EpicVideo url="https://www.epicweb.dev/workshops/testing-fundamentals/testing-asynchronous-code/testing-with-async-side-effects" />
 
-The asynchronous nature of some behaviors may be hidden from us. For example, when using React, we can update the state in response to a user request but the actual state transition cannot be accessed in test (e.g. to be awaited). It happens as a _side effect_. The thing is, we still have the intention we want to test coupled with that incaccessible side effect, so we need to account for it somehow.
+The asynchronous nature of some behaviors may be hidden from us. For example, when using React, we can update the state in response to a user request but the actual state transition cannot be accessed in test (e.g. to be awaited). It happens as a _side effect_. The thing is, we still have the intention we want to test coupled with that inaccessible side effect, so we need to account for it somehow.
 
 Properly handling side effects, especially those we don't own (like state transition, browser navigation), is the key to eliminating flakiness in tests. In the end, we want _reliable_ tests, and side effects is the biggest contributing factor that makes them unpredictable.