Merge pull request #53 from LaunchCodeEducation/chapter-6-through-10-…

…typos

Fixes typos from chapters 6-10

content/inheritance/reading/cat-classes/_index.md

@@ -7,9 +7,9 @@ originalAuthor: John Woolbright # to be set by page creator
 originalAuthorGitHub: jwoolbright23 # to be set by page creator
 reviewer: Kimberly Horan # to be set by the page reviewer
 reviewerGitHub: codinglikeagirl42 # to be set by the page reviewer
-lastEditor: # update any time edits are made after review
-lastEditorGitHub: # update any time edits are made after review
-lastMod: # UPDATE ANY TIME CHANGES ARE MADE
+lastEditor: Colin Brock # update any time edits are made after review
+lastEditorGitHub: ColinBrock # update any time edits are made after review
+lastMod: 2023-11-28 # UPDATE ANY TIME CHANGES ARE MADE
 ---
 
 Let’s revisit our `Cat` and `HouseCat` friends. In `java-web-dev-projects`, open `inheritance/testing-inheritance/tale-of-two-cats/src/main/java` and examine the two classes inside.
@@ -109,7 +109,7 @@ public HouseCat(double aWeight) {
 ```
 
 {{% notice red Warning "rocket" %}}
-The above constructor is a bad one, and is included merly to introduce syntax and usage. We would not want to have a constructor for `HouseCat` that didn't initialize an essential field such as `name`.
+The above constructor is a bad one, and is included merely to introduce syntax and usage. We would not want to have a constructor for `HouseCat` that didn't initialize an essential field such as `name`.
 {{% /notice %}}
 
 

content/spring-intro/reading/mvc/index.md

@@ -7,9 +7,9 @@ originalAuthor: Sally Steuterman # to be set by page creator
 originalAuthorGitHub: gildedgardenia # to be set by page creator
 reviewer: Courtney Frey # to be set by the page reviewer
 reviewerGitHub: speudusa # to be set by the page reviewer
-lastEditor: # update any time edits are made after review
-lastEditorGitHub: # update any time edits are made after review
-lastMod: # UPDATE ANY TIME CHANGES ARE MADE
+lastEditor: Colin Brock # update any time edits are made after review
+lastEditorGitHub: ColinBrock # update any time edits are made after review
+lastMod: 2023-11-28 # UPDATE ANY TIME CHANGES ARE MADE
 ---
 
 So far, we have been designing our applications by diagramming classes, drawing connections, and abstracting via interfaces.
@@ -23,7 +23,7 @@ Design patterns provide a set of conventions that we follow to build an applicat
 A **model** handles the data and business logic of the application. A **view** handles the user interface elements.
 A **controller** passes information from the models to the views. Controllers are the traffic cops of the application, capable of passing data back and forth to the browser in MVC web applications. This process will be covered in depth later on in this chapter.
 
-Because MVC breaks down all of the programming logic of an application into three digestable components, we can use this particular design pattern to make extensible applications.
+Because MVC breaks down all of the programming logic of an application into three digestible components, we can use this particular design pattern to make extensible applications.
 We also use MVC because it separates the components of the programs that the user interacts with from the underlying business logic.
 
 ## Spring

content/unit-testing/exercises/_index.md

@@ -7,9 +7,9 @@ originalAuthor: Sally Steuterman # to be set by page creator
 originalAuthorGitHub: gildedgardenia # to be set by page creator
 reviewer: # to be set by the page reviewer
 reviewerGitHub: # to be set by the page reviewer
-lastEditor: # update any time edits are made after review
-lastEditorGitHub: # update any time edits are made after review
-lastMod: # UPDATE ANY TIME CHANGES ARE MADE
+lastEditor: Colin Brock # update any time edits are made after review
+lastEditorGitHub: ColinBrock # update any time edits are made after review
+lastMod: 2023-11-28 # UPDATE ANY TIME CHANGES ARE MADE
 ---
 
 Work on these exercises in the IntelliJ `car-exercises` 
@@ -50,7 +50,7 @@ public void testGasTankAfterDriving() {
 Add a test for the fourth TODO, "gasTankLevel is accurate after attempting to drive past tank range".
 
 1. You're on your own for this one. You'll need to simulate the `Car`
-   travelling farther than it's `gasTankLevel` allows.
+   traveling farther than it's `gasTankLevel` allows.
 
 {{% expand "Check your solution" %}}
 

content/unit-testing/reading/junit/index.md

@@ -7,9 +7,9 @@ originalAuthor: Sally Steuterman # to be set by page creator
 originalAuthorGitHub: gildedgardenia # to be set by page creator
 reviewer: # to be set by the page reviewer
 reviewerGitHub: # to be set by the page reviewer
-lastEditor: # update any time edits are made after review
-lastEditorGitHub: # update any time edits are made after review
-lastMod: # UPDATE ANY TIME CHANGES ARE MADE
+lastEditor: Colin Brock # update any time edits are made after review
+lastEditorGitHub: ColinBrock # update any time edits are made after review
+lastMod: 2023-11-28 # UPDATE ANY TIME CHANGES ARE MADE
 ---
 
 JUnit is a library that provides the classes, methods, and assertions
@@ -124,7 +124,7 @@ Of course, `10` equals `10`. But let's run it so
 we know our test runner works. Click the green arrow to the left of 
 `public class CarTest` to run the test. Once run, you'll see a new output panel with a 
 green check mark indicating the test passed and a message stating the test passed. We 
-know now how the test runner behaves when a test passes and begin the real work of unit 
+now know how the test runner behaves when a test passes and begin the real work of unit 
 testing the `Car` class.
 
 Under your second TODO, write a test to verify that the constructor sets the 
@@ -139,7 +139,7 @@ Under your second TODO, write a test to verify that the constructor sets the
    }
 ```
 
-Here, we give the test a descriptive name, `testInitialGasTank()`, initialized a new 
+Here, we give the test a descriptive name, `testInitialGasTank()`, initialize a new 
 `Car` object, and test that the constructor correctly handles the `gasTankLevel` property.
 Run `CarTest` to see that both tests pass. 
 

content/unit-testing/reading/testing-in-java/index.md

@@ -7,9 +7,9 @@ originalAuthor: Sally Steuterman # to be set by page creator
 originalAuthorGitHub: gildedgardenia # to be set by page creator
 reviewer: # to be set by the page reviewer
 reviewerGitHub: # to be set by the page reviewer
-lastEditor: # update any time edits are made after review
-lastEditorGitHub: # update any time edits are made after review
-lastMod: # UPDATE ANY TIME CHANGES ARE MADE
+lastEditor: Colin Brock # update any time edits are made after review
+lastEditorGitHub: ColinBrock # update any time edits are made after review
+lastMod: 2023-11-28 # UPDATE ANY TIME CHANGES ARE MADE
 ---
 
 
@@ -48,7 +48,7 @@ Imagine this common workflow:
    different syntax.
 
 The features will be the same, but the implementation changes. 
-Unit tests help in this scenario in that, changes to implementation
+Unit tests help in this scenario in that changes to implementation
 should not require changes to outcome. Thus, if your tests continue
 to pass after the refactor, you can move on, knowing you have not 
 inadvertently introduced a bug. When you write tests once, they provide a code 

content/unit-testing/studio/_index.md

@@ -7,9 +7,9 @@ originalAuthor: Sally Steuterman # to be set by page creator
 originalAuthorGitHub: gildedgardenia # to be set by page creator
 reviewer: # to be set by the page reviewer
 reviewerGitHub: # to be set by the page reviewer
-lastEditor: # update any time edits are made after review
-lastEditorGitHub: # update any time edits are made after review
-lastMod: # UPDATE ANY TIME CHANGES ARE MADE
+lastEditor: Colin Brock # update any time edits are made after review
+lastEditorGitHub: ColinBrock # update any time edits are made after review
+lastMod: 2023-11-28 # UPDATE ANY TIME CHANGES ARE MADE
 ---
 
 For this studio, you will be writing unit tests to help you find 
@@ -21,7 +21,7 @@ errors in provided code.
 1. Open the `balanced-brackets` project in IntelliJ.
 1. Write unit tests to find the errors in `BalancedBrackets`.
 
-   1. The tests you write should guide how you revise the sourcecode. Use TDD to 
+   1. The tests you write should guide how you revise the source code. Use TDD to 
       first write tests that will work for the desired behavior of `BalancedBrackets`.
       When your tests fail, correct the class to pass your tests.
    1. The content of your tests is up to you, but you should write at least 12 tests.