Skip to content

style: fix typos in README #16

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 9 additions & 9 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -3,7 +3,7 @@
## Summary
This is an introduction to automated testing in JavaScript. The idea behind automated testing is to provide immediate feedback on the code you write to solve a problem, add a feature, or fix a bug. The feedback from the tests comes in the form of green passing tests or red failing tests. Tests are functions that test functions to compare the results of the actual output vs. the expected output.

Specifically, we will be working with "unit tests", as our type of test. A unit means the smallest possible block of functionality. Most frequently, this means a single user-defined function in code. Unit tests aim to test the building blocks of functionality. In this way, they test application code from the inside-out. Other types of test such as end-to-end tests test the entire application from the outside-in
Specifically, we will be working with "unit tests", as our type of test. A unit means the smallest possible block of functionality. Most frequently, this means a single user-defined function in code. Unit tests aim to test the building blocks of functionality. In this way, they test application code from the inside-out. Other types of test such as end-to-end tests test the entire application from the outside-in.

Additionally, we will be using a process called Test Driven Development, commonly called TDD, where we author tests to assert expected vs. actual results before authoring the code that produces those results. While TDD can be used on a variety of types of tests, we'll be applying the TDD workflow and process with unit tests.

Expand Down Expand Up @@ -60,7 +60,7 @@ Additionally, we will be using a process called Test Driven Development, commonl
1. Once you've copied your repo's clone address, it's time to clone the project in one of two ways:
- If you're using IntelliJ, choose New->Project From Version Control->Git and then paste in the clone address.`git clone [email protected]:your-github-username/intro-to-testing-js.git`.
- If you're using command line, then execute the following command line command: `git clone [email protected]:your-github-username/intro-to-testing-js.git`.
1. Once cloned to your projects directory, open up the project.
1. Once cloned to your project's directory, open up the project.
1. Launch `report.html` in your browser. You should see a set of green tests for the `helloWorld` function.
1. Refresh `report.html` to re-run new code in `test.js` or `code.js`. Do this any time the test or the implementation code changes.

Expand All @@ -71,9 +71,9 @@ Additionally, we will be using a process called Test Driven Development, commonl

## Exercise #0 - look, guess, test, conclude

1. Clone this repo to your projects folder following the "Getting Started" directions. Take a moment to orient yourself with the test runner, the existing tests, and the implementation inside of `code.js`.
1. Clone this repo to your project's folder following the "Getting Started" directions. Take a moment to orient yourself with the test runner, the existing tests, and the implementation inside of `code.js`.

1. Once you're setup and comfortable, go to `code.js` and change the name of the `helloWorld` function to `hello`. Then refresh `report.html` in your browser.
1. Once you're set up and comfortable, go to `code.js` and change the name of the `helloWorld` function to `hello`. Then refresh `report.html` in your browser.
- What do you notice about the test results?
- What are some ways you think we could get the tests to turn green again?
- Set the function name in `code.js` back to `helloWorld` and re-run the tests.
Expand All @@ -95,7 +95,7 @@ Additionally, we will be using a process called Test Driven Development, commonl
- Refresh `report.html` in your browser.
- Fix the syntax error and confirm that tests are all green.

1. Now, go to `code.js` and replace the function statement for `helloWorld` with a function experession. Do all the tests stay green or not? Why or why not? Double check your syntax. These are interchangeable because functions are *first class* citizens in the JS language.
1. Now, go to `code.js` and replace the function statement for `helloWorld` with a function expression. Do all the tests stay green or not? Why or why not? Double-check your syntax. These are interchangeable because functions are *first class* citizens in the JS language.
```js
// function statement syntax
function helloWorld() {
Expand Down Expand Up @@ -141,7 +141,7 @@ Our next exercise is to follow the TDD workflow to develop incremental tests and
- Step 1: The smallest possible test, now that the function exists, is to ensure that calling the function gives us a string. Inside of `tests.js`, add an assertion to `sayHello` that it "should return a string when called.". The test should look similar to `expect(typeof sayHello()).toBe("string")`
- Step 2: Run all tests to make sure that the new test starts red.
- Step 3: Have your `sayHello` function return a string. The simplest code and smallest change possible is to return an empty string `return ""`.
- Step 4: Now, run all the tests to ensure that the previously red test is now turned green by our impelementation.
- Step 4: Now, run all the tests to ensure that the previously red test is now turned green by our implementation.
- Step 5: There's nothing to refactor.
- Step 6: Repeat (Repeat the process by moving to build the next, small test)
- Always: Add, commit, and push your work to GitHub.
Expand All @@ -157,7 +157,7 @@ Our next exercise is to follow the TDD workflow to develop incremental tests and
### Exercise #4 Add another small, simple test
- Step 1: In `tests.js`, assert that `sayHello("Alex")` returns `"Hello, Alex!"`. Our first test should be *super* simple and *super* small. This means that our next test should look like `expect(sayHello("Alex")).toBe("Hello, Alex!")`.
- Step 2: Run all tests and make sure that this newly added test is red.
- Step 3: It's challenging not to jump to the "correct" answer already, but let's stay close to the TDD method. Write *just* enough code to green the test. This means making sure that the `sayHello` function definition inside of `code.js` takes an an input argument. If `input === "Alex"`, then we `return "Hello, Alex!"` else `return "Hello, Jane!"`. Don't get too fancy. A cornerstone of TDD is refactoring only once you have a handful of green tests, not just one or two with new inputs.
- Step 3: It's challenging not to jump to the "correct" answer already, but let's stay close to the TDD method. Write *just* enough code to green the test. This means making sure that the `sayHello` function definition inside of `code.js` takes an input argument. If `input === "Alex"`, then we `return "Hello, Alex!"` else `return "Hello, Jane!"`. Don't get too fancy. A cornerstone of TDD is refactoring only once you have a handful of green tests, not just one or two with new inputs.
- Step 4: Run all tests, expecting that all are now green. Does each test turn green? If so, then we can proceed. We can't refactor unless we have greened a test, even with a hard-coded implementation.
- Step 5: If you feel the urge to refactor already, hang on! Let's add one more test!
- Step 6: Repeat the TDD cycle, so let's add another test in the next exercise.
Expand All @@ -182,7 +182,7 @@ Our next exercise is to follow the TDD workflow to develop incremental tests and

### Exercise #6 Implement the refactor!
- Inside `sayHello` in `code.js`, what's a change you can identify that will improve the overall functioning of this function?
- Can you get the implmentation of `sayHello` down to a function with only one line of code inside?
- Can you get the implementation of `sayHello` down to a function with only one line of code inside?
- If we have `return "Hello, " + input + "!";`, does this work for all names?
- Does this bring up any other issues with other inputs?

Expand Down Expand Up @@ -291,7 +291,7 @@ Our next exercise is to follow the TDD workflow to develop incremental tests and
- Build up functionality one small piece at a time.
- If any input is not a number, return NaN
- Refactor, if possible
- Repeat until the tests are robust and the function works as intented.
- Repeat until the tests are robust and the function works as intended.
- Commit your work to git and push to GitHub.

## Conclusion and completeness
Expand Down