add remaining readings for module 5

Author: Shrreya

module5-testing/README.md

@@ -1 +1,42 @@
-# curriculum-backend-readings
+# Module 5: Testing
+
+Last revised: 07/12/2021
+
+## Summary
+
+No company can scale beyond a small project without automated testing. Students will
+learn about unit and integration testing, in addition to learning best practices
+surrounding writing clean, modular, and hermetic tests. This unit will emphasize not
+only writing tests as a means to verify robustness of code, but also utilizing test-writing as a developer mindset for writing safe code.
+
+## Outline
+
+- 1 [Introduction to testing [R]](../module5-testing/r1-introduction-to-testing/README.md)
+    
+- 1.1 [Testing Philosophy [R]](../module5-testing/r1.1-testing-philosphy/README.md)
+    
+- 1.2 [Types of tests [R]](../module5-testing/r1.2-types-of-tests/README.md)
+  
+- 2 [Testing in JavaScript [R]](../module5-testing/r2-testing-in-javascript/README.md)
+  
+- 2.1 [Testing examples [R]](../module5-testing/r2.1-testing-examples/README.md)
+
+- 2.2 [Mocking [R]](../module5-testing/r2.2-mocking/README.md)
+
+- 2.3 [Test coverage [R]](../module5-testing/r2.3-test-coverage/README.md)
+    
+- 2.4 [Static analysis testing [R]](../module5-testing/r2.4-static-analysis-testing/README.md)
+
+- 2.5 [CI/CD [R]](../module5-testing/r2.5-ci-cd/README.md)
+  
+- 3 [Testing Pure Functions [L]](../module5-testing/r3-testing-pure-functions/README.md)
+ 
+- 3.1 [Mocking Practice [L]](../module5-testing/r3.1-mocking-practice/README.md)
+   
+- 3.2 [Testing Controllers and API Routes [L]](../module5-testing/r3.2-testing-controllers-routes/README.md)
+
+- 3.3 [Testing Middleware [L]](../module5-testing/r3.3-testing-middleware/README.md)
+   
+- 3.4 [Testing Authenticated Code [L]](../module5-testing/r3.4-testing-authenticated-code/README.md)
+
+- 4 [Summary [R]](../module5-testing/r4-summary/README.md)

module5-testing/assets/clean-code.jpeg

@@ -0,0 +1,88 @@
+# Static Analysis Testing
+
+What are some ways to ensure clean and correct code even before we run our unit tests? Can we enforce certain best practices for all team members while they're writing the code itself? The objectives of this lesson are:
+1. Understanding the need for static analysis testing and how it is different from unit testing
+2. Understanding the different tools that help with writing well-formatted code
+
+## What is static analysis testing?
+
+Static analysis is a method of debugging by examining source code before a program is run. It’s done by analyzing a set of code against a set (or multiple sets) of coding rules. In simpler words, static analysis identifies defects before you run a program (between coding and unit testing) while dynamic analysis identifies defects after you run a program (during unit testing).
+
+So far everything we learned was related to dynamic analysis. Static analysis is the process of verifying that your code meets certain expectations without actually running it. Unlike unit and integration testing, static analysis can be performed on raw source code without the need for a web server or build process. Static analyzers typically parse your code and turn it into what is known as an abstract syntax tree. This tree is then traversed and the pieces are checked based on the rules dictated by the static analyzer. Most static analyzers also include a way for developers to write their own custom rules, but that varies from tool to tool. Static analysis is most commonly used to:
+- Ensure consistent style and formatting
+- Check for common mistakes and possible bugs
+- Limit the complexity of code
+- Verify type consistency
+- Minimize security risks
+- Keep third-party dependencies up to date
+
+There are many popular tools for implementing static analysis on JavaScript or Node.js codebases, and you can read about some of those [here](https://blog.logrocket.com/static-analysis-in-javascript-11-tools-to-help-you-catch-errors-before-users-do/).
+
+We'll look into some of the most commonly used tools, that we recommend you should use during this bootcamp as well.
+
+## ESLint
+
+[ESLint](https://eslint.org/) is probably the most used static analysis tool for JavaScript. It is mainly a tool for [linting](https://en.wikipedia.org/wiki/Lint_(software)), as in a tool that programmatically scans your code with the goal of finding issues that can lead to bugs or inconsistencies with code health and style and sometimes even fix those issues automatically.
+
+ESLint is very easy to [setup](https://www.section.io/engineering-education/node-eslint/) and also comes with many [predetermined rules](https://eslint.org/docs/rules/) that you can configure for your project. It also gives the option to extend a set of rules prepared by another reliable company or developer, so that we don't have to list down all the rules from scratch. You can ovverride a few rules if required from the extended set.
+
+You can read more about configuring ESLint [here](https://eslint.org/docs/user-guide/configuring/). Or go back to some of the previous assignments, specifically module 4 assignments which had a `.eslintrc` file.
+
+## Prettier
+
+While ESlint does take care of code formatting to a large extent, quite often it is paired with [Prettier](https://prettier.io/). Prettier focusses more on code formatting and as such is not a fully-featured linter in itself. For example, Prettier can manage code formatting rules like `max-len`, `no-mixed-spaces-and-tabs`, `keyword-spacing`, `comma-style` but cannot handle code quality rules like `no-unused-vars`, `no-extra-bind`, `no-implicit-globals` and `prefer-promise-reject-errors`. You can read more about the specific benefits of Prettier [here](https://prettier.io/docs/en/why-prettier.html).
+
+Once again Prettier is quite easy to [setup](https://sourcelevel.io/blog/how-to-setup-eslint-and-prettier-on-node) along with ESLint. You can read more about configuration [here](https://prettier.io/docs/en/install.html) and take a look at the `prettierrc` file from module 4 assignments.
+
+## VSCode Extensions
+
+We strongly recommend that you must install the extensions for ESLint and Prettier on your VSCode, that is if you haven't already.
+
+- [ESLint extension for VSCode](https://marketplace.visualstudio.com/items?itemName=dbaeumer.vscode-eslint)
+- [Prettier extension for VSCode](https://marketplace.visualstudio.com/items?itemName=esbenp.prettier-vscode)
+
+These will ensure that the rules from your project's `eslintrc` and `prettierrc` or `prettier.config` files are always applied. Your editor will highlight linting and formatting errors while you code so that you can fix them on the go, and also apply automatic formatting each time you save the file. You can read more about using these extensions on [this article](https://enlear.academy/integrating-prettier-and-eslint-with-vs-code-1d2f6fb53bc9).
+
+## Executing static analysis
+
+We can run our static analysis tools just like we executed our unit tests using the command `npm test` which was possible by defining the test script in our `package.json` files.
+```js
+{
+  ...
+  "scripts": {
+    ...
+    "test": "jest"
+  },
+  ...
+}
+```
+
+We can add a script to run ESLint as:
+```js
+"lint": "eslint ."
+```
+
+And then the command `npm run eslint` checks all JS files in our code for lint errors.
+
+However, we need some JS files to be ignored by ESLint such as those in `node_modules` or maybe if we have a `build` folder then those too. In that case, we can reuse the `.gitignore` file which already tell git to ignore tracking certain set of files and folders and modify our script to:
+```js
+"lint": "eslint --ignore-path .gitignore ."
+```
+
+Similarly, we can write another script to run prettier formatting as:
+```js
+"format": "prettier --ignore-path .gitignore --write \"**/*.+(js|json)\""
+```
+
+And voila, `npm run format` will now use prettier config rules to apply formatting corrections on al js and json files in the project, except those that should be ignored.
+
+We can also have a joint script for both lint and format as:
+```js
+"validate": "npm run format && npm run lint"
+```
+
+Now we can execute `npm run validate` before pushing any major code change to GitHub or deploying to production.
+
+Using a common set of linting and formatting rules enforced by ESLint and Prettier boost team productivity and ensure that all developers in the team are writing clean and consistent code in a shared codebase. We will try to use these tools in most assignments going forward and strongly recommend that you use them in your own projects as well. The feeling of looking at clean and readable code can often be therapeutic, given that this job can otherwise get very stressful stuck in the land of debugging. A combination of static analysis and dynamic testing leads to well-maintained and robust code!
+
+<img src="../assets/clean-code.jpeg"/>

module5-testing/r2.4-static-analysis-testing/README.md

@@ -0,0 +1,51 @@
+# CI/CD
+
+Have you heard of the terms Continuous Integration and Continuous Delivery before? Specially in the context of automated testing and it's use in DevOps. The objectives of this lesson are:
+1. To understand the role of automated testing in CI/CD
+2. Get familiar with few methodologies for implementing CI/CD checks
+
+## What is CI/CD?
+CI/CD is a method to frequently deliver apps to customers by introducing automation into the stages of app development. The main concepts attributed to CI/CD are continuous integration, continuous delivery, and continuous deployment. CI/CD is a solution to the problems integrating new code can cause for development and operations teams (AKA "integration hell").
+
+Specifically, CI/CD introduces ongoing automation and continuous monitoring throughout the lifecycle of apps, from integration and testing phases to delivery and deployment. Taken together, these connected practices are often referred to as a "CI/CD pipeline" and are supported by development and operations teams working together in an agile way with either a DevOps or site reliability engineering (SRE) approach.
+
+We will be learning about CI/CD in little bit more detail in one of the upcoming modules on Cloud Computing. In this module, we will focus on deploying automated tests during continuous integration.
+
+So far we have seen how we can run tests and static analysis while working on our code. However, in what we have learned so far there is a huge dependency of each developer to run `npm test` and `npm run lint` and `npm run format` on their local machine before pushing the code to a shared remote repository. What if a developer forgets to execute these steps? Or what if a new team member unaware of these practices ends up pushing code without executing these checks?
+
+Are you thinking what we are thinking? "Let's automate this!"
+Yup, one main approach in continuous integration is to automate the execution of tests before integrating the new incoming code changes.
+
+## Husky
+
+[Husky](https://www.npmjs.com/package/husky) is a popular tool used to enforce running checks on each devloper's local machines. It works with the concepts of Git hooks. Basically Husky can execute commands automatically in relation to git commands. So let's say, we want to ensure that no developer can commit any code that is not validated. We can configure Husky to run `npm run validate` on the pre-commit hook.
+
+All you need to do is add Husky as a dev dependency on your project.
+```bash
+npm install husky --save-dev
+```
+
+And then create a `.huskyrc` file as:
+```js
+{
+    "hooks": {
+        "pre-commit": "npm run validate"
+    }
+}
+```
+
+Now whenever a git commit is about to be performed, Husky will first run the validate script (which basically runs lint and format) and proceed or abort the commit depending on the validations.
+
+You can also configure Husky to automatically make formatting corrections and add them to the current commit. Or you can also configure Husky to run your unit tests in a pre-push hook. You can read more about setting up and using Husky in [this article](https://www.freecodecamp.org/news/how-to-add-commit-hooks-to-git-with-husky-to-automate-code-tasks/).
+
+## GitHub Actions
+
+[GitHub Actions](https://github.com/features/actions) is an awesome tool used to automate CI/CD workflows on GitHub repositories. It has many many different possibilities, but when it comes to testing it is very useful to automate the running of unit tests on a new pull request.
+
+So, consider the scenario where multiple developers are contributing to a shared codebase using a single remote repository on GitHub. Each developer would work on dedicated branches and then open a pull request (PR) into the main branch once they are ready to have their code merged. In order to make sure that the code changes of a PR does not break any existing features, we can use GitHub Actions to automatically run tests and block merging in case any tests fail.
+
+We can setup a workflow for GitHub Actions by adding a `.yml` file in the repository that has all the configuration options for running tests. Take a look at [this example](https://lannonbr.com/blog/2020-03-30-github-actions-ci-tests) in which the workflow runs `npm install` and `npm test` in an Ubuntu environment using Node 12.
+
+You can look at the `.github` folder on any of your previous assignments which had automated tests for submission, and explore the configuration files. You can see the results of these tests on any of your PRs in the tab called "Checks". In fact, if your PR passed the tests on GitHub Actions workflow you will see a green check mark next to the PR title. And for details of the tests execution you can explore the "Checks" tab.
+
+There are many more tools and options for CI/CD which we will learn about soon, but one of the main components is setting up automated tests and now you know how to setup the same using the above tools.

module5-testing/r2.5-ci-cd/README.md

@@ -0,0 +1,3 @@
+# Testing Pure Functions
+
+[Assignment repo link](https://github.com/ReCoded-Org/curriculum-backend-testing-pure-functions)

module5-testing/r3-testing-pure-functions/README.md

@@ -0,0 +1,3 @@
+# Mocking Practice
+
+[Assignment repo link](https://github.com/ReCoded-Org/curriculum-backend-mocking-practice)

module5-testing/r3.1-mocking-practice/README.md

@@ -0,0 +1,3 @@
+# Testing Controllers and API Routes
+
+[Assignment repo link](https://github.com/ReCoded-Org/curriculum-backend-testing-controllers-routes)

module5-testing/r3.2-testing-controllers-routes/README.md

@@ -0,0 +1,3 @@
+# Testing Middleware
+
+[Assignment repo link](https://github.com/ReCoded-Org/curriculum-backend-testing-middleware)

module5-testing/r3.3-testing-middleware/README.md

@@ -0,0 +1,3 @@
+# Testing Authenticated Code
+
+[Assignment repo link](https://github.com/ReCoded-Org/curriculum-backend-testing-authenticated-code)

module5-testing/r3.4-testing-authenticated-code/README.md

@@ -0,0 +1,5 @@
+# Summary
+
+You have now learned how to write unit tests and enforce static analysis checks on your backend projects. You have also practiced the testing mindset and approach of test driven development in testing different parts of the backend such as functions, controllers, routes and middleware. A backend developer who also has a strong knowledge of testing can be trusted to write really solid, error-free code that is easy to maintain over the long-term.
+
+So now that we know so much about building backend applications and testing them, we're getting close to learning all about deploying our applications to the production stage. And one important aspect of production ready applications is a solid architecture and design. We'll learn all about this in the next module!