Merge remote-tracking branch 'upstream/master' into contrib-format

.all-contributorsrc

@@ -1650,6 +1650,15 @@
       "contributions": [
         "content"
       ]
+    },
+    {
+      "login": "Alex-Dumitru",
+      "name": "Alex Dumitru",
+      "avatar_url": "https://avatars.githubusercontent.com/u/43738450?v=4",
+      "profile": "https://github.com/Alex-Dumitru",
+      "contributions": [
+        "content"
+      ]
     }
   ],
   "projectName": "nodebestpractices",

README.md

@@ -9,7 +9,7 @@
 <br/>
 
 <div align="center">
-  <img src="https://img.shields.io/badge/⚙%20Item%20count%20-%20102%20Best%20Practices-blue.svg" alt="102 items"/> <img id="last-update-badge" src="https://img.shields.io/badge/%F0%9F%93%85%20Last%20update%20-%20February%2007%2C%202022-green.svg" alt="Last update: February 07, 2022" /> <img src="https://img.shields.io/badge/ %E2%9C%94%20Updated%20For%20Version%20-%20Node%2014.0.0-brightgreen.svg" alt="Updated for Node 14.0.0"/>
+  <img src="https://img.shields.io/badge/⚙%20Item%20count%20-%20102%20Best%20Practices-blue.svg" alt="102 items"/> <img id="last-update-badge" src="https://img.shields.io/badge/%F0%9F%93%85%20Last%20update%20-%20February%2013%2C%202022-green.svg" alt="Last update: February 13, 2022" /> <img src="https://img.shields.io/badge/ %E2%9C%94%20Updated%20For%20Version%20-%20Node%2014.0.0-brightgreen.svg" alt="Updated for Node 14.0.0"/>
 </div>
 
 <br/>
@@ -1810,6 +1810,7 @@ Thanks goes to these wonderful people who have contributed to this repository!
     <td align="center"><a href="https://github.com/koyanyaroo"><img src="https://avatars.githubusercontent.com/u/9715368?v=4?s=100" width="100px;" alt=""/><br /><sub><b>Fajar Budhi Iswanda</b></sub></a><br /><a href="#content-koyanyaroo" title="Content">🖋</a></td>
     <td align="center"><a href="https://github.com/jutiger"><img src="https://avatars.githubusercontent.com/u/97490806?v=4?s=100" width="100px;" alt=""/><br /><sub><b>이주호</b></sub></a><br /><a href="#content-jutiger" title="Content">🖋</a></td>
     <td align="center"><a href="https://github.com/MisterSingh"><img src="https://avatars.githubusercontent.com/u/44462019?v=4?s=100" width="100px;" alt=""/><br /><sub><b>Singh</b></sub></a><br /><a href="#content-MisterSingh" title="Content">🖋</a></td>
+    <td align="center"><a href="https://github.com/Alex-Dumitru"><img src="https://avatars.githubusercontent.com/u/43738450?v=4?s=100" width="100px;" alt=""/><br /><sub><b>Alex Dumitru</b></sub></a><br /><a href="#content-Alex-Dumitru" title="Content">🖋</a></td>
   </tr>
 </table>
 

sections/testingandquality/refactoring.korean.md

@@ -0,0 +1,41 @@
+# Refactoring
+
+<br/><br/>
+
+### One Paragraph Explainer
+
+리팩토링은 반복적인 개발 흐름에서 중요한 과정이다. 중복 코드, 긴 메서드, 긴 매개 변수 목록과 같은 "코드 스멜"(불량 코딩 관행)을 제거하면 코드가 향상되고 유지 관리가 더욱 용이해집니다. 정적 분석 도구를 사용하면 이러한 코드 스멜을 찾고 리팩토링에 대한 프로세스를 구축하는 데 도움이 됩니다. CI 빌드에 이러한 도구를 추가하면 품질 검사 프로세스를 자동화하는 데 도움이 됩니다. CI가 소나 또는 코드 기후와 같은 도구와 통합될 경우 코드 스멜을 감지하고 작성자에게 문제 해결 방법을 알려주면 빌드가 실패합니다. 이러한 정적 분석 도구는 ESLint와 같은 보풀 도구를 보완합니다. 대부분의 보풀 도구는 단일 파일에서 들여쓰기와 누락된 세미콜론과 같은 코드 스타일(일부는 긴 함수처럼 코드 냄새가 나기도 함)에 초점을 맞추고 정적 분석 도구는 단일 파일과 여러 파일에 있는 코드 냄새(중복 코드, 복잡성 분석 등)를 찾는 데 초점을 맞춥니다.
+
+<br/><br/>
+
+### Martin Fowler - Chief Scientist at ThoughtWorks
+
+책, "JavaScript 수정: 불량 코드를 정상 코드로 변경"
+
+> 리팩토링은 기존 코드베이스의 설계를 개선하기 위한 통제된 기술이다.
+
+<br/><br/>
+
+### Evan Burchard - Web Development Consultant and Author
+
+책, "JavaScript 수정: 불량 코드를 정상 코드로 변경"
+
+> 사용하는 프레임워크나
+> "컴파일-투-JS" 언어 또는 라이브러리가 무엇이든
+> 자바스크립트의 기본 품질이 낮으면 버그와 성능에 대한 우려는 항상 문제가 됩니다.
+
+<br/><br/>
+
+### Example: Complex methods analysis with CodeClimate (commercial)
+
+![alt text](../../assets/images/codeanalysis-climate-complex-methods.PNG "Complex methods analysis")
+
+### Example: Code analysis trends and history with CodeClimate (commercial)
+
+![alt text](../../assets/images/codeanalysis-climate-history.PNG "Code analysis history")
+
+### Example: Code analysis summary and trends with SonarQube (commercial)
+
+![alt text](../../assets/images/codeanalysis-sonarqube-dashboard.PNG "Code analysis history")
+
+<br/><br/>

sections/testingandquality/refactoring.md

@@ -4,29 +4,30 @@
 
 ### One Paragraph Explainer
 
-리팩토링은 반복적인 개발 흐름에서 중요한 과정이다. 중복 코드, 긴 메서드, 긴 매개 변수 목록과 같은 "코드 스멜"(불량 코딩 관행)을 제거하면 코드가 향상되고 유지 관리가 더욱 용이해집니다. 정적 분석 도구를 사용하면 이러한 코드 스멜을 찾고 리팩토링에 대한 프로세스를 구축하는 데 도움이 됩니다. CI 빌드에 이러한 도구를 추가하면 품질 검사 프로세스를 자동화하는 데 도움이 됩니다. CI가 소나 또는 코드 기후와 같은 도구와 통합될 경우 코드 스멜을 감지하고 작성자에게 문제 해결 방법을 알려주면 빌드가 실패합니다. 이러한 정적 분석 도구는 ESLint와 같은 보풀 도구를 보완합니다. 대부분의 보풀 도구는 단일 파일에서 들여쓰기와 누락된 세미콜론과 같은 코드 스타일(일부는 긴 함수처럼 코드 냄새가 나기도 함)에 초점을 맞추고 정적 분석 도구는 단일 파일과 여러 파일에 있는 코드 냄새(중복 코드, 복잡성 분석 등)를 찾는 데 초점을 맞춥니다.
+Refactoring is an important process in the iterative development flow. Removing "Code Smells" (bad coding practices) such as Duplicated Code, Long Methods, Long Parameter list will improve your code and making it more maintainable. Using a static analysis tools will assist you in finding these code smells and build a process around refactoring. Adding these tools to your CI build will help automate the quality checking process. If your CI integrates with a tool like Sonar or Code Climate, the build will fail if it detects code smells and inform the author on how to address the issue. Theses static analysis tools will complement lint tools such as ESLint. Most linting tools will focus on code styles like indentation and missing semicolons (although some will find code smells like Long functions) in a single file while static analysis tools will focus on finding code smells (duplicate code, complexity analysis, etc) that are in single files and multiple files.
 
 <br/><br/>
 
+
 ### Martin Fowler - Chief Scientist at ThoughtWorks
 
-책, "JavaScript 수정: 불량 코드를 정상 코드로 변경"
+ From the book, "Refactoring - Improving the Design of Existing Code"
 
-> 리팩토링은 기존 코드베이스의 설계를 개선하기 위한 통제된 기술이다.
+ > Refactoring is a controlled technique for improving the design of an existing code base.
 
 <br/><br/>
 
 ### Evan Burchard - Web Development Consultant and Author
 
-책, "JavaScript 수정: 불량 코드를 정상 코드로 변경"
+ From the book, "Refactoring JavaScript: Turning Bad Code into Good Code"
 
-> 사용하는 프레임워크나
+ > No matter what framework or
-> "컴파일-투-JS" 언어 또는 라이브러리가 무엇이든
+“compiles-to-JS” language or library you use, bugs and performance concerns
-> 자바스크립트의 기본 품질이 낮으면 버그와 성능에 대한 우려는 항상 문제가 됩니다.
+will always be an issue if the underlying quality of your JavaScript is poor.
 
 <br/><br/>
 
-### Example: Complex methods analysis with CodeClimate (commercial)
+ ### Example: Complex methods analysis with CodeClimate (commercial)
 
 ![alt text](../../assets/images/codeanalysis-climate-complex-methods.PNG "Complex methods analysis")
 
@@ -38,4 +39,5 @@
 
 ![alt text](../../assets/images/codeanalysis-sonarqube-dashboard.PNG "Code analysis history")
 
+
 <br/><br/>

sections/testingandquality/test-middlewares.korean.md

@@ -0,0 +1,30 @@
+# Test your middlewares in isolation
+
+<br/><br/>
+
+### One Paragraph Explainer
+
+미들웨어 테스트는 시스템의 작은 부분을 차지하며 라이브 Express 서버가 필요하기 때문에 대부분 미들웨어 테스트를 회피합니다. 두 가지 이유 모두 틀렸습니다. 미들웨어는 작지만 요청의 전부 또는 대부분에 영향을 미치며 '{req,res}' JS 개체를 가져오는 순수 함수로 쉽게 테스트할 수 있습니다. 미들웨어 함수를 테스트하려면 해당 함수를 호출하고 {req,res}개 개체와의 상호 작용에 대해 [예를 들어 Sinon 사용](https://www.npmjs.com/package/sinon)))을 스파이하여 함수가 올바른 동작을 수행했는지 확인해야 합니다. 라이브러리 [node-controls-products](https://www.npmjs.com/package/node-mocks-http)는 더 나아가서 {req,res}개의 객체의 동작에 대한 스파이 활동과 함께 인자를 분석합니다. 예를 들어 res 개체에 설정된 http 상태가 예상과 일치하는지 여부를 주장할 수 있습니다(아래 예 참조).
+
+<br/><br/>
+
+### Code example: Testing middleware in isolation
+
+```javascript
+//the middleware we want to test
+const unitUnderTest = require("./middleware");
+const httpMocks = require("node-mocks-http");
+//Jest syntax, equivalent to describe() & it() in Mocha
+test("A request without authentication header, should return http status 403", () => {
+  const request = httpMocks.createRequest({
+    method: "GET",
+    url: "/user/42",
+    headers: {
+      authentication: "",
+    },
+  });
+  const response = httpMocks.createResponse();
+  unitUnderTest(request, response);
+  expect(response.statusCode).toBe(403);
+});
+```

sections/testingandquality/test-middlewares.md

@@ -4,7 +4,7 @@
 
 ### One Paragraph Explainer
 
-미들웨어 테스트는 시스템의 작은 부분을 차지하며 라이브 Express 서버가 필요하기 때문에 대부분 미들웨어 테스트를 회피합니다. 두 가지 이유 모두 틀렸습니다. 미들웨어는 작지만 요청의 전부 또는 대부분에 영향을 미치며 '{req,res}' JS 개체를 가져오는 순수 함수로 쉽게 테스트할 수 있습니다. 미들웨어 함수를 테스트하려면 해당 함수를 호출하고 {req,res}개 개체와의 상호 작용에 대해 [예를 들어 Sinon 사용](https://www.npmjs.com/package/sinon)))을 스파이하여 함수가 올바른 동작을 수행했는지 확인해야 합니다. 라이브러리 [node-controls-products](https://www.npmjs.com/package/node-mocks-http)는 더 나아가서 {req,res}개의 객체의 동작에 대한 스파이 활동과 함께 인자를 분석합니다. 예를 들어 res 개체에 설정된 http 상태가 예상과 일치하는지 여부를 주장할 수 있습니다(아래 예 참조).
+Many avoid Middleware testing because they represent a small portion of the system and require a live Express server. Both reasons are wrong — Middlewares are small but affect all or most of the requests and can be tested easily as pure functions that get `{req,res}` JS objects. To test a middleware function one should just invoke it and spy ([using Sinon for example](https://www.npmjs.com/package/sinon)) on the interaction with the {req,res} objects to ensure the function performed the right action. The library [node-mock-http](https://www.npmjs.com/package/node-mocks-http) takes it even further and factors the {req,res} objects along with spying on their behavior. For example, it can assert whether the http status that was set on the res object matches the expectation (See example below)
 
 <br/><br/>
 
@@ -20,11 +20,11 @@ test("A request without authentication header, should return http status 403", (
     method: "GET",
     url: "/user/42",
     headers: {
-      authentication: "",
+      authentication: ""
-    },
+    }
   });
   const response = httpMocks.createResponse();
   unitUnderTest(request, response);
   expect(response.statusCode).toBe(403);
 });
-```
+```