Merge pull request goldbergyoni#1133 from jutiger/korea-translation-j…

…utiger

Korea translation jutiger

sections/testingandquality/citools.korean.md

@@ -4,7 +4,7 @@
 
 ### One Paragraph Explainer
 
-The CI world used to be the flexibility of [Jenkins](https://jenkins.io/) vs the simplicity of SaaS vendors. The game is now changing as SaaS providers like [CircleCI](https://circleci.com/) and [Travis](https://travis-ci.org/) offer robust solutions including Docker containers with minimum setup time while Jenkins tries to compete on 'simplicity' segment as well. Though one can setup rich CI solution in the cloud, should it required to control the finest details Jenkins is still the platform of choice. The choice eventually boils down to which extent the CI process should be customized: free and setup free cloud vendors allow to run custom shell commands, custom docker images, adjust the workflow, run matrix builds and other rich features. However, if controlling the infrastructure or programming the CI logic using a formal programming language like Java is desired - Jenkins might still be the choice. Otherwise, consider opting for the simple and setup free cloud option
+CI 환경은 [Jenkins](https://jenkins.io/)의 유연성과 SaaS 공급업체의 단순성을 비교한 결과였습니다. 현재 [CircleCI](https://circleci.com/) 및 [Travis](https://travis-ci.org/))와 같은 SaaS 제공업체가 최소 설정 시간을 가진 도커 컨테이너를 포함한 강력한 솔루션을 제공하는 반면 Jenkins는 '유효성' 부문에서도 경쟁하려고 노력함에 따라 판도가 바뀌고 있다. 클라우드에서 풍부한 CI 솔루션을 설정할 수 있지만, 세부 정보를 제어해야 하는 경우 Jenkins가 여전히 선택하는 플랫폼입니다. 선택은 결국 CI 프로세스를 어느 정도까지 커스터마이징해야 하는지로 귀결됩니다. 무료 및 설치 클라우드 공급업체는 맞춤형 셸 명령, 사용자 지정 도커 이미지 실행, 워크플로우 조정, 매트릭스 빌드 실행 및 기타 다양한 기능을 사용할 수 있습니다. 그러나 인프라를 제어하거나 Java와 같은 공식 프로그래밍 언어를 사용하여 CI 로직을 프로그래밍하려는 경우에는 Jenkins를 선택할 수 있습니다. 그렇지 않으면 간편하고 무료 클라우드 설정 옵션을 선택하는 것이 좋습니다.
 
 <br/><br/>
 
@@ -33,7 +33,7 @@ jobs:
           command: npm test
       - run:
           name: Generate code coverage
-          command: './node_modules/.bin/nyc report --reporter=text-lcov'      
+          command: './node_modules/.bin/nyc report --reporter=text-lcov'
       - store_artifacts:
           path: coverage
           prefix: coverage
@@ -44,7 +44,7 @@ jobs:
 
 ![alt text](../../assets/images/circleci.png "API error handling")
 
-### Jenkins - sophisticated and robust CI 
+### Jenkins - sophisticated and robust CI
 
 ![alt text](../../assets/images/jenkins_dashboard.png "API error handling")
 

sections/testingandquality/refactoring.md

@@ -4,30 +4,29 @@
 
 ### One Paragraph Explainer
 
-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.
+리팩토링은 반복적인 개발 흐름에서 중요한 과정이다. 중복 코드, 긴 메서드, 긴 매개 변수 목록과 같은 "코드 스멜"(불량 코딩 관행)을 제거하면 코드가 향상되고 유지 관리가 더욱 용이해집니다. 정적 분석 도구를 사용하면 이러한 코드 스멜을 찾고 리팩토링에 대한 프로세스를 구축하는 데 도움이 됩니다. CI 빌드에 이러한 도구를 추가하면 품질 검사 프로세스를 자동화하는 데 도움이 됩니다. CI가 소나 또는 코드 기후와 같은 도구와 통합될 경우 코드 스멜을 감지하고 작성자에게 문제 해결 방법을 알려주면 빌드가 실패합니다. 이러한 정적 분석 도구는 ESLint와 같은 보풀 도구를 보완합니다. 대부분의 보풀 도구는 단일 파일에서 들여쓰기와 누락된 세미콜론과 같은 코드 스타일(일부는 긴 함수처럼 코드 냄새가 나기도 함)에 초점을 맞추고 정적 분석 도구는 단일 파일과 여러 파일에 있는 코드 냄새(중복 코드, 복잡성 분석 등)를 찾는 데 초점을 맞춥니다.
 
 <br/><br/>
 
-
 ### Martin Fowler - Chief Scientist at ThoughtWorks
 
- From the book, "Refactoring - Improving the Design of Existing Code"
+책, "JavaScript 수정: 불량 코드를 정상 코드로 변경"
 
- > Refactoring is a controlled technique for improving the design of an existing code base.
+> 리팩토링은 기존 코드베이스의 설계를 개선하기 위한 통제된 기술이다.
 
 <br/><br/>
 
 ### Evan Burchard - Web Development Consultant and Author
 
- From the book, "Refactoring JavaScript: Turning Bad Code into Good Code"
+책, "JavaScript 수정: 불량 코드를 정상 코드로 변경"
 
- > No matter what framework or
-“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.
+> 사용하는 프레임워크나
+> "컴파일-투-JS" 언어 또는 라이브러리가 무엇이든
+> 자바스크립트의 기본 품질이 낮으면 버그와 성능에 대한 우려는 항상 문제가 됩니다.
 
 <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")
 
@@ -39,5 +38,4 @@ will always be an issue if the underlying quality of your JavaScript is poor.
 
 ![alt text](../../assets/images/codeanalysis-sonarqube-dashboard.PNG "Code analysis history")
 
-
 <br/><br/>

sections/testingandquality/test-middlewares.md

@@ -4,7 +4,7 @@
 
 ### One Paragraph Explainer
 
-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)
+미들웨어 테스트는 시스템의 작은 부분을 차지하며 라이브 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/>
 
@@ -20,8 +20,8 @@ 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);