Merge pull request #22 from ReCoded-Org/module5

Module 5 full content

Author: Shrreya

module2-databases/README.md

@@ -4,7 +4,7 @@ Last revised: 31/10/2021
 
 ## Summary
 Web applications that persist data between visits inevitably use a database. Students
-familiarize themselves with the relational and non-relational databases used in today’s
+familiarize themselves with the relational and non-relational databases used in today's
 ecosystem and their query languages: MySQL, PostgreSQL, MongoDB. Students
 explore the advantages and disadvantages of each technology, understanding the
 appropriate use cases for each one.

module4-authentication-and-security/r1.3-authentication-persistence/README.md

@@ -188,17 +188,17 @@ When the JWT is passed back to the server in the header, we check the claims, an
 
 ## Pros and Cons of JSON Web Tokens
 
-JWTs are becoming more and more ubiquitous. Customer identity and access management (CIAM) providers everywhere are pushing JWTs as the silver bullet for everything. JWTs are pretty cool, but let’s talk about some of the downsides of JWTs and some of their strong benefits.
+JWTs are becoming more and more ubiquitous. Customer identity and access management (CIAM) providers everywhere are pushing JWTs as the silver bullet for everything. JWTs are pretty cool, but let's talk about some of the downsides of JWTs and some of their strong benefits.
 
 ### PRO: JWTs are portable units of identity
 
-That means they contain identity information as JSON and can be passed around to services and applications. Any service or application can verify a JWT itself. The service/application receiving a JWT doesn’t need to ask the identity provider that generated the JWT if it is valid or check any database for it. Once a JWT is verified, the service or application can use the data inside it to take action on behalf of the user. Plus, it works across different clients and domains.
+That means they contain identity information as JSON and can be passed around to services and applications. Any service or application can verify a JWT itself. The service/application receiving a JWT doesn't need to ask the identity provider that generated the JWT if it is valid or check any database for it. Once a JWT is verified, the service or application can use the data inside it to take action on behalf of the user. Plus, it works across different clients and domains.
 
 ### PRO: Token-based Authentication is more Scalable and Efficient
 
 Imagine your app has billions of users, and each of them creates a session. Eventually, the session storage will become pretty big and harder to maintain.
 
-Tokens on the other hand are required to be stored on the user’s end, they offer a scalable solution.
+Tokens on the other hand are required to be stored on the user's end, they offer a scalable solution.
 
 Moreover, the server just needs to create and verify the tokens along with the information, which means that maintaining more users on a website or application at once is possible without any hassle.
 
@@ -212,9 +212,9 @@ This helps in encouraging more collaboration opportunities between enterprises a
 
 Since tokens like JWT are stateless, only a secret key can validate it when received at a server-side application, which was used to create it.
 
-Hence they’re considered the best and the most secure way of offering authentication.
+Hence they're considered the best and the most secure way of offering authentication.
 
-Tokens act as a storage for the user’s credentials and when the token travels between the server or the web browser, the stored credentials are never compromised.
+Tokens act as a storage for the user's credentials and when the token travels between the server or the web browser, the stored credentials are never compromised.
 
 ### CON: Compromised Secret Key
 
@@ -238,13 +238,13 @@ To solve this problem, most applications use refresh tokens. Refresh tokens are
 
 The overall size of a JWT is quite more than that of a normal session token, which makes it longer whenever more data is added to it.
 
-So, if you’re adding more claims in the token, it will impact the overall loading speed and thus hamper the user experience.
+So, if you're adding more claims in the token, it will impact the overall loading speed and thus hamper the user experience.
 
 This situation can be fixed if the right development practices are followed and minimum but essential data is added to the JWT.
 
-### CON: JWTs aren’t easily revocable
+### CON: JWTs aren't easily revocable
 
-This means that a JWT could be valid even though the user’s account has been suspended or deleted. Some solutions around this are available but they mostly require trips to the identity provider or the database, which JWT is essentially developed to minimize.
+This means that a JWT could be valid even though the user's account has been suspended or deleted. Some solutions around this are available but they mostly require trips to the identity provider or the database, which JWT is essentially developed to minimize.
 
 So if your app has the potential to deactivate or revoke user access frequently, think twice before using JWTs.
 

module4-authentication-and-security/r1.5-authorization-through-middleware/README.md

@@ -11,7 +11,7 @@ This lesson objectives are:
 
 ## Middleware
 
-Middleware are functions that have access to the [request object](https://expressjs.com/en/4x/api.html#req) (`req`), the [response object](https://expressjs.com/en/4x/api.html#res) (`res`), and the next middleware function in the application’s request-response cycle. The next middleware function is commonly denoted by a variable named `next`.
+Middleware are functions that have access to the [request object](https://expressjs.com/en/4x/api.html#req) (`req`), the [response object](https://expressjs.com/en/4x/api.html#res) (`res`), and the next middleware function in the application's request-response cycle. The next middleware function is commonly denoted by a variable named `next`.
 
 ```js
 const loggerMiddleware = (req, res, next) => {
@@ -115,7 +115,7 @@ app.use(function (err, req, res, next) {
 
 Usually, an error logging service like [sentry](https://sentry.io/) is also contacted in this middleware to log and track the error so you get notified when your app has run into an unhandled exception, with the required request-response details that can help the developers reproduce the error to fix it.
 
-> ⚠️ **Warning**: Error-handling middleware always takes **four** arguments. You must provide four arguments to identify it as an error-handling middleware function. Even if you don’t need to use the next object, you must specify it to maintain the signature. Otherwise, the next object will be interpreted as regular middleware and will fail to handle errors.
+> ⚠️ **Warning**: Error-handling middleware always takes **four** arguments. You must provide four arguments to identify it as an error-handling middleware function. Even if you don't need to use the next object, you must specify it to maintain the signature. Otherwise, the next object will be interpreted as regular middleware and will fail to handle errors.
 
 ## Auth guard middleware
 

module4-authentication-and-security/r2-auth-schemes/README.md

@@ -19,16 +19,16 @@ Whenever users go to a domain that requires authentication, they are redirected
 
 ### How does SSO work?
 
-SSO works based upon a trust relationship set up between an application, known as the service provider, and an identity provider, like [OneLogin](https://www.onelogin.com/) or [Auth0](https://auth0.com/). This trust relationship is often based upon a certificate that is exchanged between the identity provider and the service provider. This certificate can be used to sign identity information that is being sent from the identity provider to the service provider so that the service provider knows it is coming from a trusted source. In SSO, this identity data takes the form of JWTs which contain identifying bits of information about the user like a user’s email address or a username.
+SSO works based upon a trust relationship set up between an application, known as the service provider, and an identity provider, like [OneLogin](https://www.onelogin.com/) or [Auth0](https://auth0.com/). This trust relationship is often based upon a certificate that is exchanged between the identity provider and the service provider. This certificate can be used to sign identity information that is being sent from the identity provider to the service provider so that the service provider knows it is coming from a trusted source. In SSO, this identity data takes the form of JWTs which contain identifying bits of information about the user like a user's email address or a username.
 
 The login flow usually looks like this:
 
 1. A user browses to the application or website they want access to, aka, the Service Provider.
 2. The Service Provider sends a token that contains some information about the user, like their email address, to the SSO system, aka, the Identity Provider, as part of a request to authenticate the user.
 3. The Identity Provider first checks to see whether the user has already been authenticated, in which case it will grant the user access to the Service Provider application and skip to step 5.
-4. If the user hasn’t logged in, they will be prompted to do so by providing the credentials required by the Identity Provider. This could simply be a username and password or it might include some other form of authentication like a One-Time Password (OTP).
+4. If the user hasn't logged in, they will be prompted to do so by providing the credentials required by the Identity Provider. This could simply be a username and password or it might include some other form of authentication like a One-Time Password (OTP).
 5. Once the Identity Provider validates the credentials provided, it will send a token back to the Service Provider confirming a successful authentication.
-6. This token is passed through the user’s browser to the Service Provider.
+6. This token is passed through the user's browser to the Service Provider.
 7. The token that is received by the Service Provider is validated according to the trust relationship that was set up between the Service Provider and the Identity Provider during the initial configuration.
 8. The user is granted access to the Service Provider.
 
@@ -176,7 +176,7 @@ This scheme was prominent in many apps, like asking for your bank username and p
 ![Shady Budget Planner](../assets/shady-budget-planner.jpg)
 _Image rights belong to [Okta Developers](https://developer.okta.com/blog/2019/10/21/illustrated-guide-to-oauth-and-oidc)_
 
-You should never be required to share your username and password, your credentials, to another service. There’s no guarantee that an organization will keep your credentials safe, or guarantee their service won’t access more of your personal information than necessary. It might sound crazy, but some applications still try to get away with this!
+You should never be required to share your username and password, your credentials, to another service. There's no guarantee that an organization will keep your credentials safe, or guarantee their service won't access more of your personal information than necessary. It might sound crazy, but some applications still try to get away with this!
 
 To the rescue comes OAuth, an agreed-upon standard to securely allow one service to access data from another.
 

module4-authentication-and-security/r3-other-security-vulnerabilities-practices/README.md

@@ -13,7 +13,7 @@ In this lesson you will learn about:
 
 ## Cross-site request forgery (CSRF)
 
-[CSRF](https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html) is an attack that forces an end user to execute unwanted actions on a web application in which they’re currently authenticated. With a little help of social engineering (such as sending a link via email or chat), an attacker may trick the users of a web application into executing actions of the attacker’s choosing. If the victim is a normal user, a successful CSRF attack can force the user to perform state changing requests like transferring funds, changing their email address, and so forth. If the victim is an administrative account, CSRF can compromise the entire web application.
+[CSRF](https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html) is an attack that forces an end user to execute unwanted actions on a web application in which they're currently authenticated. With a little help of social engineering (such as sending a link via email or chat), an attacker may trick the users of a web application into executing actions of the attacker's choosing. If the victim is a normal user, a successful CSRF attack can force the user to perform state changing requests like transferring funds, changing their email address, and so forth. If the victim is an administrative account, CSRF can compromise the entire web application.
 
 ### How does it work?
 

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)