diff --git a/content/inheritance/reading/cat-classes/_index.md b/content/inheritance/reading/cat-classes/_index.md index 3290296..17d15d8 100644 --- a/content/inheritance/reading/cat-classes/_index.md +++ b/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 %}} diff --git a/content/spring-intro/reading/mvc/index.md b/content/spring-intro/reading/mvc/index.md index 127e316..31a2b96 100644 --- a/content/spring-intro/reading/mvc/index.md +++ b/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 diff --git a/content/unit-testing/exercises/_index.md b/content/unit-testing/exercises/_index.md index 84dc592..5e415ff 100644 --- a/content/unit-testing/exercises/_index.md +++ b/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" %}} diff --git a/content/unit-testing/reading/junit/index.md b/content/unit-testing/reading/junit/index.md index 39c83c0..0c8d4fa 100644 --- a/content/unit-testing/reading/junit/index.md +++ b/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. diff --git a/content/unit-testing/reading/testing-in-java/index.md b/content/unit-testing/reading/testing-in-java/index.md index d38fa91..e2a4fa7 100644 --- a/content/unit-testing/reading/testing-in-java/index.md +++ b/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 diff --git a/content/unit-testing/studio/_index.md b/content/unit-testing/studio/_index.md index f3e7a70..b0b003e 100644 --- a/content/unit-testing/studio/_index.md +++ b/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.