From 0fd894175f3236c4f27fa8026c954ba07f4f59ae Mon Sep 17 00:00:00 2001 From: Aaron McAdam Date: Thu, 31 Oct 2024 15:57:50 +0000 Subject: [PATCH 1/6] 02-01: typo fix --- exercises/02.test-structure/01.solution.assertions/README.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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. From 814b963c540360f87f5857d058818408b84046ee Mon Sep 17 00:00:00 2001 From: Aaron McAdam Date: Thu, 31 Oct 2024 15:58:24 +0000 Subject: [PATCH 2/6] 02-04: typo --- exercises/02.test-structure/04.problem.hooks/README.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/exercises/02.test-structure/04.problem.hooks/README.mdx b/exercises/02.test-structure/04.problem.hooks/README.mdx index a4846bb..3e13880 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 it was intended 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_: A test must fail if, and only if, the intention behind the system is not met. From 6af677e007cb2b8a87c26ad8f96ea8f5e8703022 Mon Sep 17 00:00:00 2001 From: Aaron McAdam Date: Thu, 31 Oct 2024 15:59:45 +0000 Subject: [PATCH 3/6] 02-04: grammar --- exercises/02.test-structure/04.problem.hooks/README.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/exercises/02.test-structure/04.problem.hooks/README.mdx b/exercises/02.test-structure/04.problem.hooks/README.mdx index 3e13880..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 intended 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. From d7941850342c2aac577ab868c03958eeb653c5e8 Mon Sep 17 00:00:00 2001 From: Aaron McAdam Date: Thu, 31 Oct 2024 16:08:54 +0000 Subject: [PATCH 4/6] 02-04: typo in solution --- exercises/02.test-structure/04.solution.hooks/README.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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. From ea1b63babdbe0711d6f79cbb03a994bf08592aa0 Mon Sep 17 00:00:00 2001 From: Aaron McAdam Date: Thu, 31 Oct 2024 16:10:32 +0000 Subject: [PATCH 5/6] 02-finished: fix typo --- exercises/02.test-structure/FINISHED.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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. From b51162e9e914a37a643acd106c63ef59ea447b68 Mon Sep 17 00:00:00 2001 From: Aaron McAdam Date: Thu, 31 Oct 2024 17:48:24 +0000 Subject: [PATCH 6/6] 03-02: typo --- exercises/03.async/02.solution.rejections/README.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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: