[mabel] Edits to express.js lessons

Author: mabelleeyanhwa

docs/backend-web-development/express-middleware.md

@@ -15,7 +15,7 @@ You could also imagine that it is a factory. For the request "assembly line", th
 The request object, response object and the `next` function are passed to each middleware function. To move on to the `next` function to be run in the stack (could be a middleware function or handler function), the `next` function needs to be called.
 
 ```js
-app.use(function(req, res, next) {
+app.use((req, res, next) => {
   console.log("Method: " + req.method);
   console.log("Path: " + req.url);
   next();
@@ -75,7 +75,7 @@ Refer to the script: [Express.js playground: middleware_example_1](https://githu
 Add a middleware function that will be called for all routes. It has no mount path.
 
 ```js
-app.use(function (req, res, next) {
+app.use((req, res, next) => {
   console.log("common middleware function was called!");
   next();
 });
@@ -84,7 +84,7 @@ app.use(function (req, res, next) {
 Add a middleware function that will only be called if a request goes to the `/users` route.
 
 ```js
-app.use("/users", function (req, res, next) {
+app.use("/users", (req, res, next) => {
   console.log("middleware function for /users was called!");
   next();
 });
@@ -93,7 +93,7 @@ app.use("/users", function (req, res, next) {
 Add a middleware function that will only be called if a POST request goes to the `/users` route.
 
 ```js
-app.post("/users", function (req, res, next) {
+app.post("/users", (req, res, next) => {
   console.log("second middleware function for /users was called!");
   next();
 });
@@ -102,7 +102,7 @@ app.post("/users", function (req, res, next) {
 Add a middleware function that will only be called if a GET request goes to the `/users` route.
 
 ```js
-app.get("/users", function (req, res, next) {
+app.get("/users", (req, res, next) => {
   console.log("third middleware function for /users was called!");
   next();
 });
@@ -192,7 +192,7 @@ You are also able to add middleware on the router level instead of the applicati
 Add a middleware function that is executed for every request to the router. It has no mount path.
 
 ```js
-var router = express.Router();
+const router = express.Router();
 
 router.use((req, res, next) => {
   console.log("I am middleware for the router");

docs/backend-web-development/express-parsing-request-body.md

@@ -60,7 +60,8 @@ Add more API endpoints to the previous songs API that we had:
 Add middleware for parsing JSON request body.
 
 1. Route: POST /songs
-   HTTP Response status code: 201
+
+HTTP Response status code: 201
 
 Add a new song with id, and return new song
 
@@ -84,7 +85,8 @@ Expected response:
 ```
 
 2. Route: GET /songs/:id
-   HTTP Response status code: 200
+
+HTTP Response status code: 200
 
 Return a song with id using route parameters.
 
@@ -99,7 +101,8 @@ if route path is /songs/1, expected response is:
 ```
 
 3. Route: PUT /songs/:id
-   HTTP Response status code: 200
+
+HTTP Response status code: 200
 
 Replace a song with id, and return modified song
 
@@ -125,7 +128,8 @@ Expected response:
 ```
 
 4. Route: DELETE /songs/:id
-   HTTP Response status code: 200
+
+HTTP Response status code: 200
 
 delete a song with id, and return deleted song
 

docs/backend-web-development/express-responses.md

@@ -122,7 +122,8 @@ No. The more status codes your API deals with, the more status codes you have to
 Implement an API with the following endpoint:
 
 1. Route: GET /songs
-   HTTP Response status code: 200
+
+HTTP Response status code: 200
 
 Expected response:
 

docs/backend-web-development/express-testing.md

@@ -22,17 +22,17 @@ The type of tests we are going to write is called integration test.
 
 Integration tests, as the name suggests, tests that the different layers of your application (e.g. app, router, request handlers, any middleware, models and database) works as expected when integrated together.
 
-In contrast, there is another type of tests, called Unit Test, which focus on testing a module/class/function works alone.
+In contrast, there is another type of tests, called Unit Test, which focus on testing a module/class/function works alone. For example, react testing library is often used to unit test a single React component.
 
 ## Tests for API
 
 To verify that your API works as expected, usually you need to send some requests to a running instance of your application, and check the responses. This can be done manually using tools like Postman or Insomnia, but we prefer to automate those tests.
 
 To automate those tests, the tests need to act as API consumers, issuing requests and verifying responses.
 
-### Using Jest as a testing framework
+## Using Jest as a testing framework for testing our API
 
-#### Filename Conventions for Jest
+### Filename Conventions for Jest
 
 Jest will look for test files at:
 
@@ -45,26 +45,38 @@ It is recommended to put the test files next to the code they are testing so tha
 
 Read more about this in the [Jest documentation](https://jestjs.io/docs/en/configuration#testregex-string--arraystring).
 
-#### Asynchronous tests with Jest
+### Asynchronous tests with Jest
 
 We will like to send requests to test our API. Requests are asynchronous, therefore we need to have asynchronous tests.
 
 How can we do this with Jest?
 
 - Add the `async` keyword
-- Call `done` when you’re done with your tests
+- Call `done` when you’re done with your tests if you want to tell Jest exactly where to end the test (optional)
+
+`done` is a callback passed by Jest. Jest will wait until the done callback is called before finishing the test. Read more about it in the [Jest documentation](https://jestjs.io/docs/en/asynchronous#callbacks).
+
+```js
+it("Async test should do nothing", async () => {
+  // Do async operations here
+});
+```
+
+using the done callback is optional
 
 ```js
-it("Async test should do nothing", async done => {
+it("Async test should do nothing", async (done) => {
   // Do async operations here
   done();
 });
 ```
 
-### SuperTest
+## SuperTest
 
 Previously, we mentioned that we will like to send requests to test our API. You can use libraries like [SuperTest](https://github.com/visionmedia/supertest).
 
+SuperTest wraps around SuperAgent, which is another API for creating HTTP requests / making calls to other APIs.
+
 ### Installation
 
 Install SuperTest and save it to your package.json file as a development dependency:
@@ -73,18 +85,18 @@ Install SuperTest and save it to your package.json file as a development depende
 npm install supertest --save-dev
 ```
 
-### Testing with Jest and SuperTest
+## Testing with Jest and SuperTest
 
 SuperTest works without any framework but in our case we will use it along with Jest, since we are already using Jest as our testing framework.
 
-#### Refactoring for tests
+### Refactoring for tests
 
 Before we can start testing with SuperTest, we need to refactor our code to allow our server to be started by SuperTest for each of the tests.
 
 Currently, our app looks like this in many of the examples where the routes exist in the same file as the server.
 
 ```js
-// testing_example_1.js
+// app.js
 app.get("/", (req, res) => {
   res.send("Welcome to my homepage");
 });
@@ -101,45 +113,44 @@ This doesn’t work when creating tests because it starts listening to one port.
 To solve this problem, you need to `export` the app without listening to it. Replace the `app.listen` code with `module.exports = app;`.
 
 ```js
-// testing_example_1.js
+// app.js
 module.exports = app;
 ```
 
 Now how do we run the server for development or production purposes? (not testing)
 
-Normally when we are exporting the app like above, we do this in a file called **app.js**. (for this example, we shall just use testing_example_1.js)
+Normally when we are exporting the app like above, we do this in a file called **app.js**.
 
 We create a new file called **index.js** to start the server and make the server listen to port 3000.
-(for this example, the file shall be called testing_example_1_index.js)
 
 We `require` the previous file to import the app.
 
 ```js
-// testing_example_1_index.js
-const app = require("./testing_example_1");
+// index.js
+const app = require("./app");
 const PORT = 3000;
 
 app.listen(PORT, () =>
   console.log(`Server running at http://localhost:${PORT}`)
 );
 ```
 
-Run `node testing_example_1_index.js` again to start your server. Ensure that it still works.
+Run `node index.js` again to start your server. Ensure that it still works.
 
-#### Writing tests
+### Writing tests with SuperTest
 
 First we will have to import SuperTest and our app.
 
 ```js
-// testing_example_1.test.js
+// app.test.js
 const request = require("supertest");
-const app = require("./testing_example_1");
+const app = require("./app");
 ```
 
 Test that Jest works
 
 ```js
-describe("testing_example_1", () => {
+describe("App", () => {
   it("Testing to see if Jest works", () => {
     expect(1).toBe(1);
   });
@@ -149,11 +160,11 @@ describe("testing_example_1", () => {
 Let's add our first test for the GET "/" route! We shall write it in a Promises way...
 
 ```js
-describe("testing_example_1", () => {
+describe("App", () => {
   it("GET / should respond with Welcome to my homepage", () => {
     return request(app)
       .get("/")
-      .then(response => {
+      .then((response) => {
         expect(response.status).toEqual(200);
         expect(response.text).toEqual("Welcome to my homepage");
       });
@@ -164,13 +175,10 @@ describe("testing_example_1", () => {
 Oh no. Let's use async/await instead.
 
 ```js
-describe("testing_example_1", () => {
-  it("GET / should respond with Welcome to my homepage", async done => {
-    const response = await request(app)
-      .get("/")
-      .expect(200);
+describe("App", () => {
+  it("GET / should respond with Welcome to my homepage", async () => {
+    const response = await request(app).get("/").expect(200);
     expect(response.text).toEqual("Welcome to my homepage");
-    done();
   });
 });
 ```
@@ -180,17 +188,13 @@ Looks nicer! It passes with green.
 What if we destructure the response to extract `text`?
 
 ```js
-it("should respond correctly", async done => {
-  const { text } = await request(app)
-    .get("/")
-    .expect(200);
+it("should respond correctly", async () => {
+  const { text } = await request(app).get("/").expect(200);
   expect(text).toEqual("Welcome to my homepage");
-  done();
 });
 ```
 
 `request(app)` passes the app to SuperTest. We are then able to send GET, POST, PUT, PATCH and DELETE requests.
-`done` is a callback passed by Jest. Jest will wait until the done callback is called before finishing the test. Read more about it in the [Jest documentation](https://jestjs.io/docs/en/asynchronous#callbacks).
 
 How should we test this POST "/" route? We will need to POST some JSON and non-JSON content to the server, and then check its response.
 
@@ -212,22 +216,52 @@ Using SuperTest, we can easily send strings or JSON to the server:
 
 ```js
 describe("POST /", () => {
-  it("should respond correctly when sending json", async done => {
+  it("should respond correctly when sending json", async () => {
     const { text } = await request(app)
       .post("/")
       .send({ thisIsJson: "json!" })
       .expect(200);
     expect(text).toEqual("Thanks for the JSON!");
-    done();
   });
 
-  it("should respond with status 400 and correct string when sending non-json", async done => {
+  it("should respond with status 400 and correct string when sending non-json", async () => {
     const { text } = await request(app)
       .post("/")
       .send("This is not json!")
       .expect(400);
     expect(text).toEqual("Server wants application/json!");
-    done();
   });
 });
 ```
+
+### Accessing agent in SuperTest
+
+```js
+const request = require("supertest");
+var app = require("./app");
+
+const agent = request.agent(app);
+```
+
+After accessing the agent, you can use the agent directly.
+
+For example,
+
+```js
+const agent = request.agent(app);
+
+it("should respond correctly", async () => {
+  const { text } = await agent.get("/").expect(200);
+  expect(text).toEqual("Welcome to my homepage");
+});
+```
+
+When should we use the agent directly?
+
+There are some cases where we need to reuse the agent again. For example, we might need to persist cookies that were saved.
+
+Check the [github page for supertest](https://github.com/visionmedia/supertest) for an example on how to access the agent in SuperTest and reuse the agent to persist a request and its cookies.
+
+## Exercises 
+
+Add tests to the songs API we have been building.