mirror of
https://github.com/goldbergyoni/nodebestpractices.git
synced 2025-10-29 00:19:14 +08:00
rename english files to korean
This commit is contained in:
41
sections/testingandquality/refactoring.korean.md
Normal file
41
sections/testingandquality/refactoring.korean.md
Normal file
@ -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)
|
||||
|
||||

|
||||
|
||||
### Example: Code analysis trends and history with CodeClimate (commercial)
|
||||
|
||||

|
||||
|
||||
### Example: Code analysis summary and trends with SonarQube (commercial)
|
||||
|
||||

|
||||
|
||||
<br/><br/>
|
||||
30
sections/testingandquality/test-middlewares.korean.md
Normal file
30
sections/testingandquality/test-middlewares.korean.md
Normal file
@ -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);
|
||||
});
|
||||
```
|
||||
Reference in New Issue
Block a user