From b4d38c71aca21a55610efe59d587744de7e19ffe Mon Sep 17 00:00:00 2001 From: koDaegon Date: Wed, 16 Oct 2019 06:49:07 -0400 Subject: [PATCH 1/5] Update draft translation :tada: --- content/docs/testing.md | 35 +++++++++++++++++++---------------- 1 file changed, 19 insertions(+), 16 deletions(-) diff --git a/content/docs/testing.md b/content/docs/testing.md index 5bccd1fc4..b86bbb124 100644 --- a/content/docs/testing.md +++ b/content/docs/testing.md @@ -1,40 +1,43 @@ --- id: testing -title: Testing Overview +title: 테스팅 개요 permalink: docs/testing.html redirect_from: - "community/testing.html" next: testing-recipes.html --- -You can test React components similar to testing other JavaScript code. - -There are a few ways to test React components. Broadly, they divide into two categories: +다른 JavaScript 코드와 비슷한 방법으로 React 컴포넌트를 테스트 할 수 있습니다. +React 컴포넌트를 테스트 할수 있는 몇가지 방법이 있는데 크게는 2가지 카테고리로 나누어집니다. * **Rendering component trees** in a simplified test environment and asserting on their output. -* **Running a complete app** in a realistic browser environment (also known as “end-to-end” tests). +* **컴포넌트 트리 렌더링** : 간략화된 테스팅 환경 및 출력값이 확실한 경우. +* **Running a complete app** in a realistic browser environment (also known as “end-to-end” tests). +* **완성된 앱에서 실행**: 현실적 브라우저 환경안에서("엔드 투 엔드" 테스트라고 알려져 있습니다.) This documentation section focuses on testing strategies for the first case. While full end-to-end tests can be very useful to prevent regressions to important workflows, such tests are not concerned with React components in particular, and are out of scope of this section. +이 문서 섹션은 첫번째 경우에 대한 테스팅 전략에 초점을 맞추고 있습니다. 풀 엔드투엔트 테스트는 중요한 워크플로우의 퇴행을 막기 위해 매우 유용하지만 이러한 테스트는 특정한 React 컴포넌트를 관련되어 있지않습니다. 그리고 이들은 이 세션의 범위를 벗어 납니다. ### Tradeoffs {#tradeoffs} - +### 트레이드오프 {#tradeoffs} ? 상호교환 When choosing testing tools, it is worth considering a few tradeoffs: - +테스팅 도구를 선택할때 몇가지 트레이드오프를 생각하는 것은 의미있는 일입니다. * **Iteration speed vs Realistic environment:** Some tools offer a very quick feedback loop between making a change and seeing the result, but don't model the browser behavior precisely. Other tools might use a real browser environment, but reduce the iteration speed and are flakier on a continuous integration server. +* **Iteration speed vs Realistic environment:** 몇몇 툴은 제공하는데 매우 빠른 피드백 루프를 변경사항이 있거나 결과 값을 보는 사이에서 그러나 브라우저 행동을 정확히 모델하지 않습니다. 다른 툴은 아마 사용되나 현실적 브라우저 환경해서 그러나 반복 속도를 줄이고 더 연약 합니다. 지속정 통합 서버 환경에서 * **How much to mock:** With components, the distinction between a "unit" and "integration" test can be blurry. If you're testing a form, should its test also test the buttons inside of it? Or should a button component have its own test suite? Should refactoring a button ever break the form test? - +* **How much to mock:** 컴포넌트와 함게 '유닛'테스트와 '통합'테스트의 차이는 정확하지 않습니다. 하나의 폼을 테스팅한다고 할 때 이 테스트는 또한 테버튼의 안의 부분에서 테스트 되어지나요? 또는 버튼 컴포넌트는 자기자신의 알맞은 테스트를 할수 있나요? 리팩토링된 버튼이 폼 테스트에 오류를 일으키 나요? Different answers may work for different teams and products. - +각각의 팀 과 제품에 따라 다른 답이 적용 될 수 있습니다. ### Recommended Tools {#tools} - +### 추천 방법 {#tools} **[Jest](https://facebook.github.io/jest/)** is a JavaScript test runner that lets you access the DOM via [`jsdom`](/docs/testing-environments.html#mocking-a-rendering-surface). While jsdom is only an approximation of how the browser works, it is often good enough for testing React components. Jest provides a great iteration speed combined with powerful features like mocking [modules](/docs/testing-environments.html#mocking-modules) and [timers](/docs/testing-environments.html#mocking-timers) so you can have more control over how the code executes. - +**[Jest](https://facebook.github.io/jest/)**는 JavaScript 테스트 러너 입니다.DOM에 접근하게 하는 [`jsdom`](/docs/testing-environments.html#mocking-a-rendering-surface)을 통해서 jsdom은 단지 어떻게 브라우저가 작동하는지에 대한 대략적 개요 입니다. 하지만 이는 종종 React 컴포넌트를 테스팅 하기에 충분 합니다. Jest는 mocking [modules](/docs/testing-environments.html#mocking-modules)과 [timers](/docs/testing-environments.html#mocking-timers) 같은 파워풀한 특징과 결합되어 휼륭한 반복 속도를제공합니다. 그래서 더 많은 코드 제어를 가집니다. **[React Testing Library](https://testing-library.com/react)** is a set of helpers that let you test React components without relying on their implementation details. This approach makes refactoring a breeze and also nudges you towards best practices for accessibility. Although it doesn't provide a way to "shallowly" render a component without its children, a test runner like Jest lets you do this by [mocking](/docs/testing-recipes.html#mocking-modules). - +**[React Testing Library](https://testing-library.com/react)**는 실행 디테일을 가지지 않는 React 컴포넌트를 테스트하게 하는 도구 모음입니다. 이러한 접근은 리팩토링을 수월하게 하며 접근성에 대한 가장 좋은 연습을 가능하게 합니다. 자식 컴포넌트를 가지지 않는 컴포넌트에 대한 얕은 렌더링 방법을 제공하지 않더라도 Jest와 같은 테스트 러너는 [mocking](/docs/testing-recipes.html#mocking-modules)에 의해 위를 가능하게 합니다. ### Learn More {#learn-more} - +### 더 보기 {#learn-more} This section is divided in two pages: - -- [Recipes](/docs/testing-recipes.html): Common patterns when writing tests for React components. -- [Environments](/docs/testing-environments.html): What to consider when setting up a testing environment for React components. +두개의 페이지로 나누어저있습니다. +- [Recipes](/docs/testing-recipes.html): React 컴포넌트에 대한 테스트를 작성할 때 흔한 패턴 +- [Environments](/docs/testing-environments.html): React 컴포넌트에 대한 테스팅 환경을 설정할 때 고려해야 할 것 From 68026d35114f1687648e206615a5dfaae9a03fb2 Mon Sep 17 00:00:00 2001 From: koDaegon Date: Wed, 16 Oct 2019 23:40:17 -0400 Subject: [PATCH 2/5] Update half review and still require for the equivalant of some words --- content/docs/testing.md | 17 +++++++---------- 1 file changed, 7 insertions(+), 10 deletions(-) diff --git a/content/docs/testing.md b/content/docs/testing.md index b86bbb124..d56772150 100644 --- a/content/docs/testing.md +++ b/content/docs/testing.md @@ -14,19 +14,17 @@ React 컴포넌트를 테스트 할수 있는 몇가지 방법이 있는데 크 * **컴포넌트 트리 렌더링** : 간략화된 테스팅 환경 및 출력값이 확실한 경우. * **Running a complete app** in a realistic browser environment (also known as “end-to-end” tests). -* **완성된 앱에서 실행**: 현실적 브라우저 환경안에서("엔드 투 엔드" 테스트라고 알려져 있습니다.) -This documentation section focuses on testing strategies for the first case. While full end-to-end tests can be very useful to prevent regressions to important workflows, such tests are not concerned with React components in particular, and are out of scope of this section. -이 문서 섹션은 첫번째 경우에 대한 테스팅 전략에 초점을 맞추고 있습니다. 풀 엔드투엔트 테스트는 중요한 워크플로우의 퇴행을 막기 위해 매우 유용하지만 이러한 테스트는 특정한 React 컴포넌트를 관련되어 있지않습니다. 그리고 이들은 이 세션의 범위를 벗어 납니다. +* **완성된 앱에서 실행**: 현실적 브라우저 환경("엔드 투 엔드" 테스트라고 알려져 있습니다.) +이 문서 섹션은 아주 기본 테스팅 전략에 초점을 맞추고 있습니다. 풀 엔드투엔트 테스트는 중요한 워크플로우의 퇴행을 방지 하기 위해 매우 유용하지만 이러한 테스트들은 특정한 React 컴포넌트와 관련되어 있지않습니다. 그리고 이들은 이 세션의 범위를 벗어 납니다. -### Tradeoffs {#tradeoffs} ### 트레이드오프 {#tradeoffs} ? 상호교환 -When choosing testing tools, it is worth considering a few tradeoffs: 테스팅 도구를 선택할때 몇가지 트레이드오프를 생각하는 것은 의미있는 일입니다. -* **Iteration speed vs Realistic environment:** Some tools offer a very quick feedback loop between making a change and seeing the result, but don't model the browser behavior precisely. Other tools might use a real browser environment, but reduce the iteration speed and are flakier on a continuous integration server. -* **Iteration speed vs Realistic environment:** 몇몇 툴은 제공하는데 매우 빠른 피드백 루프를 변경사항이 있거나 결과 값을 보는 사이에서 그러나 브라우저 행동을 정확히 모델하지 않습니다. 다른 툴은 아마 사용되나 현실적 브라우저 환경해서 그러나 반복 속도를 줄이고 더 연약 합니다. 지속정 통합 서버 환경에서 -* **How much to mock:** With components, the distinction between a "unit" and "integration" test can be blurry. If you're testing a form, should its test also test the buttons inside of it? Or should a button component have its own test suite? Should refactoring a button ever break the form test? -* **How much to mock:** 컴포넌트와 함게 '유닛'테스트와 '통합'테스트의 차이는 정확하지 않습니다. 하나의 폼을 테스팅한다고 할 때 이 테스트는 또한 테버튼의 안의 부분에서 테스트 되어지나요? 또는 버튼 컴포넌트는 자기자신의 알맞은 테스트를 할수 있나요? 리팩토링된 버튼이 폼 테스트에 오류를 일으키 나요? +* **반복작업 속도 vs 현실적인 개발 환경** 몇몇 도구들은 변경사항이 생기고 결과 값이 출력되는 과정에서 매우 빠른 피드백 루프를 제공하지만 브라우저 동작을 정확히 구현하지 않습니다. 다른 도구들이 현실적 브라우저 환경에서 사용되지만 반복 작업 속도를 저하시키고 지속적 통합 서버 환경에서 더 연약 합니다. + +* **How much to mock** With components, the distinction between a "unit" and "integration" test can be blurry. If you're testing a form, should its test also test the buttons inside of it? Or should a button component have its own test suite? Should refactoring a button ever break the form test? + +* **How much to mock** 컴포넌트와 함께 '유닛'테스트와 '통합'테스트의 차이는 정확하지 않습니다. 하나의 폼을 테스팅한다고 할 때 이 테스트는 또한 테버튼의 안의 부분에서 테스트 되어지나요? 또는 버튼 컴포넌트는 자기자신의 알맞은 테스트를 할수 있나요? 리팩토링된 버튼이 폼 테스트에 오류를 일으키 나요? Different answers may work for different teams and products. 각각의 팀 과 제품에 따라 다른 답이 적용 될 수 있습니다. ### Recommended Tools {#tools} @@ -37,7 +35,6 @@ Different answers may work for different teams and products. **[React Testing Library](https://testing-library.com/react)**는 실행 디테일을 가지지 않는 React 컴포넌트를 테스트하게 하는 도구 모음입니다. 이러한 접근은 리팩토링을 수월하게 하며 접근성에 대한 가장 좋은 연습을 가능하게 합니다. 자식 컴포넌트를 가지지 않는 컴포넌트에 대한 얕은 렌더링 방법을 제공하지 않더라도 Jest와 같은 테스트 러너는 [mocking](/docs/testing-recipes.html#mocking-modules)에 의해 위를 가능하게 합니다. ### Learn More {#learn-more} ### 더 보기 {#learn-more} -This section is divided in two pages: 두개의 페이지로 나누어저있습니다. - [Recipes](/docs/testing-recipes.html): React 컴포넌트에 대한 테스트를 작성할 때 흔한 패턴 - [Environments](/docs/testing-environments.html): React 컴포넌트에 대한 테스팅 환경을 설정할 때 고려해야 할 것 From 489ca1b4467e2ef0433ba8eab789ad1dd2f1d1b2 Mon Sep 17 00:00:00 2001 From: koDaegon Date: Thu, 31 Oct 2019 15:00:40 +0900 Subject: [PATCH 3/5] Update Testing Overview page Korean translation :tada: --- content/docs/nav.yml | 2 +- content/docs/testing.md | 35 ++++++++++++++++------------------- 2 files changed, 17 insertions(+), 20 deletions(-) diff --git a/content/docs/nav.yml b/content/docs/nav.yml index a27e7fd5d..87ba7fac4 100644 --- a/content/docs/nav.yml +++ b/content/docs/nav.yml @@ -128,7 +128,7 @@ - title: Testing items: - id: testing - title: Testing Overview + title: 테스팅 개요 - id: testing-recipes title: Testing Recipes - id: testing-environments diff --git a/content/docs/testing.md b/content/docs/testing.md index d56772150..1151bcc5d 100644 --- a/content/docs/testing.md +++ b/content/docs/testing.md @@ -7,34 +7,31 @@ redirect_from: next: testing-recipes.html --- -다른 JavaScript 코드와 비슷한 방법으로 React 컴포넌트를 테스트 할 수 있습니다. +다른 JavaScript 코드와 비슷한 방법으로 React 컴포넌트를 테스트할 수 있습니다. -React 컴포넌트를 테스트 할수 있는 몇가지 방법이 있는데 크게는 2가지 카테고리로 나누어집니다. -* **Rendering component trees** in a simplified test environment and asserting on their output. +React 컴포넌트를 테스트할 수 있는 몇 가지 방법이 있는데 크게는 2가지 카테고리로 나누어집니다. * **컴포넌트 트리 렌더링** : 간략화된 테스팅 환경 및 출력값이 확실한 경우. +* **완성된 앱에서의 테스트** : 현실적 브라우저 환경("엔드 투 엔드" 테스트라고 알려져 있습니다.) -* **Running a complete app** in a realistic browser environment (also known as “end-to-end” tests). -* **완성된 앱에서 실행**: 현실적 브라우저 환경("엔드 투 엔드" 테스트라고 알려져 있습니다.) -이 문서 섹션은 아주 기본 테스팅 전략에 초점을 맞추고 있습니다. 풀 엔드투엔트 테스트는 중요한 워크플로우의 퇴행을 방지 하기 위해 매우 유용하지만 이러한 테스트들은 특정한 React 컴포넌트와 관련되어 있지않습니다. 그리고 이들은 이 세션의 범위를 벗어 납니다. +이 문서 섹션은 아주 기본 테스팅 전략에 초점을 맞추고 있습니다. 풀 엔드투엔드 테스트는 중요한 워크플로의 퇴행을 방지하기 위해 매우 유용하지만 이러한 테스트들은 특정한 React 컴포넌트와 관련되어 있지 않습니다. 그리고 이들은 이 세션의 범위를 벗어납니다. ### 트레이드오프 {#tradeoffs} ? 상호교환 -테스팅 도구를 선택할때 몇가지 트레이드오프를 생각하는 것은 의미있는 일입니다. -* **반복작업 속도 vs 현실적인 개발 환경** 몇몇 도구들은 변경사항이 생기고 결과 값이 출력되는 과정에서 매우 빠른 피드백 루프를 제공하지만 브라우저 동작을 정확히 구현하지 않습니다. 다른 도구들이 현실적 브라우저 환경에서 사용되지만 반복 작업 속도를 저하시키고 지속적 통합 서버 환경에서 더 연약 합니다. +테스팅 도구를 선택할 때 몇 가지 트레이드오프를 생각하는 것은 의미 있는 일입니다. -* **How much to mock** With components, the distinction between a "unit" and "integration" test can be blurry. If you're testing a form, should its test also test the buttons inside of it? Or should a button component have its own test suite? Should refactoring a button ever break the form test? +* **반복작업 속도 vs 현실적인 개발 환경** : 몇몇 도구들은 변경사항이 생기고 결과 값이 출력되는 과정에서 매우 빠른 피드백 루프를 제공하지만 브라우저 동작을 정확히 구현하지 않습니다. 다른 도구들이 현실적 브라우저 환경에서 사용되지만 반복 작업 속도를 저하시키고 지속적 통합 서버 환경에서 더 연약합니다. + +* **얼마나 다양한 방법을 통해 실제 테스트 환경의 동작을 테스트할 것인가?** 컴포넌트 안에서는 '유닛'테스트와 '통합'테스트의 차이는 명확하지 않습니다. 하나의 폼을 테스팅 한다고 할 때 테스트는 또한 버튼의 안의 부분에서 이루어지나요? 또는 버튼 컴포넌트에 알맞은 테스트를 할 수 있나요? 리팩 토링된 버튼이 폼 테스트에 오류를 일으키나요? + +각각의 팀과 제품에 따라 다른 답이 적용될 수 있습니다. -* **How much to mock** 컴포넌트와 함께 '유닛'테스트와 '통합'테스트의 차이는 정확하지 않습니다. 하나의 폼을 테스팅한다고 할 때 이 테스트는 또한 테버튼의 안의 부분에서 테스트 되어지나요? 또는 버튼 컴포넌트는 자기자신의 알맞은 테스트를 할수 있나요? 리팩토링된 버튼이 폼 테스트에 오류를 일으키 나요? -Different answers may work for different teams and products. -각각의 팀 과 제품에 따라 다른 답이 적용 될 수 있습니다. -### Recommended Tools {#tools} ### 추천 방법 {#tools} -**[Jest](https://facebook.github.io/jest/)** is a JavaScript test runner that lets you access the DOM via [`jsdom`](/docs/testing-environments.html#mocking-a-rendering-surface). While jsdom is only an approximation of how the browser works, it is often good enough for testing React components. Jest provides a great iteration speed combined with powerful features like mocking [modules](/docs/testing-environments.html#mocking-modules) and [timers](/docs/testing-environments.html#mocking-timers) so you can have more control over how the code executes. -**[Jest](https://facebook.github.io/jest/)**는 JavaScript 테스트 러너 입니다.DOM에 접근하게 하는 [`jsdom`](/docs/testing-environments.html#mocking-a-rendering-surface)을 통해서 jsdom은 단지 어떻게 브라우저가 작동하는지에 대한 대략적 개요 입니다. 하지만 이는 종종 React 컴포넌트를 테스팅 하기에 충분 합니다. Jest는 mocking [modules](/docs/testing-environments.html#mocking-modules)과 [timers](/docs/testing-environments.html#mocking-timers) 같은 파워풀한 특징과 결합되어 휼륭한 반복 속도를제공합니다. 그래서 더 많은 코드 제어를 가집니다. -**[React Testing Library](https://testing-library.com/react)** is a set of helpers that let you test React components without relying on their implementation details. This approach makes refactoring a breeze and also nudges you towards best practices for accessibility. Although it doesn't provide a way to "shallowly" render a component without its children, a test runner like Jest lets you do this by [mocking](/docs/testing-recipes.html#mocking-modules). -**[React Testing Library](https://testing-library.com/react)**는 실행 디테일을 가지지 않는 React 컴포넌트를 테스트하게 하는 도구 모음입니다. 이러한 접근은 리팩토링을 수월하게 하며 접근성에 대한 가장 좋은 연습을 가능하게 합니다. 자식 컴포넌트를 가지지 않는 컴포넌트에 대한 얕은 렌더링 방법을 제공하지 않더라도 Jest와 같은 테스트 러너는 [mocking](/docs/testing-recipes.html#mocking-modules)에 의해 위를 가능하게 합니다. -### Learn More {#learn-more} +**[Jest](https://facebook.github.io/jest/)**는 JavaScript 테스트 러너입니다. DOM에 접근하게 하는 [`jsdom`](/docs/testing-environments.html#mocking-a-rendering-surface)을 통해서 jsdom은 단지 어떻게 브라우저가 작동하는지에 대한 대략적 개요입니다. 하지만 이는 종종 React 컴포넌트를 테스팅 하기에 충분합니다. Jest는 mocking [modules](/docs/testing-environments.html#mocking-modules)과 [timers](/docs/testing-environments.html#mocking-timers) 같은 파워풀한 특징과 결합되어 훌륭한 반복속도를 제공합니다. 그래서 더 많은 코드 제어를 가집니다. + + +**[React Testing Library](https://testing-library.com/react)**는 실행 디테일을 가지지 않는 React 컴포넌트를 테스트하게 하는 도구 모음입니다. 이러한 접근은 리팩 토링을 수월하게 하며 접근성에 대한 가장 좋은 연습을 가능하게 합니다. 자식 컴포넌트를 가지지 않는 컴포넌트에 대한 얕은 렌더링 방법을 제공하지 않더라도 Jest와 같은 테스트 러너는 [mocking](/docs/testing-recipes.html#mocking-modules)에 의해 위를 가능하게 합니다. + ### 더 보기 {#learn-more} -두개의 페이지로 나누어저있습니다. +두 개의 페이지로 나누어 저 있습니다. - [Recipes](/docs/testing-recipes.html): React 컴포넌트에 대한 테스트를 작성할 때 흔한 패턴 - [Environments](/docs/testing-environments.html): React 컴포넌트에 대한 테스팅 환경을 설정할 때 고려해야 할 것 From 1295e0d29d6140a4347a97b1fa52f18f228f564e Mon Sep 17 00:00:00 2001 From: koDaegon Date: Thu, 31 Oct 2019 15:08:48 +0900 Subject: [PATCH 4/5] Update line arrangements as orignal documentation --- content/docs/testing.md | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/content/docs/testing.md b/content/docs/testing.md index 1151bcc5d..ff4a905da 100644 --- a/content/docs/testing.md +++ b/content/docs/testing.md @@ -10,6 +10,7 @@ next: testing-recipes.html 다른 JavaScript 코드와 비슷한 방법으로 React 컴포넌트를 테스트할 수 있습니다. React 컴포넌트를 테스트할 수 있는 몇 가지 방법이 있는데 크게는 2가지 카테고리로 나누어집니다. + * **컴포넌트 트리 렌더링** : 간략화된 테스팅 환경 및 출력값이 확실한 경우. * **완성된 앱에서의 테스트** : 현실적 브라우저 환경("엔드 투 엔드" 테스트라고 알려져 있습니다.) @@ -17,21 +18,23 @@ React 컴포넌트를 테스트할 수 있는 몇 가지 방법이 있는데 크 ### 트레이드오프 {#tradeoffs} ? 상호교환 + 테스팅 도구를 선택할 때 몇 가지 트레이드오프를 생각하는 것은 의미 있는 일입니다. * **반복작업 속도 vs 현실적인 개발 환경** : 몇몇 도구들은 변경사항이 생기고 결과 값이 출력되는 과정에서 매우 빠른 피드백 루프를 제공하지만 브라우저 동작을 정확히 구현하지 않습니다. 다른 도구들이 현실적 브라우저 환경에서 사용되지만 반복 작업 속도를 저하시키고 지속적 통합 서버 환경에서 더 연약합니다. - * **얼마나 다양한 방법을 통해 실제 테스트 환경의 동작을 테스트할 것인가?** 컴포넌트 안에서는 '유닛'테스트와 '통합'테스트의 차이는 명확하지 않습니다. 하나의 폼을 테스팅 한다고 할 때 테스트는 또한 버튼의 안의 부분에서 이루어지나요? 또는 버튼 컴포넌트에 알맞은 테스트를 할 수 있나요? 리팩 토링된 버튼이 폼 테스트에 오류를 일으키나요? 각각의 팀과 제품에 따라 다른 답이 적용될 수 있습니다. ### 추천 방법 {#tools} -**[Jest](https://facebook.github.io/jest/)**는 JavaScript 테스트 러너입니다. DOM에 접근하게 하는 [`jsdom`](/docs/testing-environments.html#mocking-a-rendering-surface)을 통해서 jsdom은 단지 어떻게 브라우저가 작동하는지에 대한 대략적 개요입니다. 하지만 이는 종종 React 컴포넌트를 테스팅 하기에 충분합니다. Jest는 mocking [modules](/docs/testing-environments.html#mocking-modules)과 [timers](/docs/testing-environments.html#mocking-timers) 같은 파워풀한 특징과 결합되어 훌륭한 반복속도를 제공합니다. 그래서 더 많은 코드 제어를 가집니다. +**[Jest](https://facebook.github.io/jest/)**는 JavaScript 테스트 러너입니다. DOM에 접근하게 하는 [`jsdom`](/docs/testing-environments.html#mocking-a-rendering-surface)을 통해서 jsdom은 단지 어떻게 브라우저가 작동하는지에 대한 대략적 개요입니다. 하지만 이는 종종 React 컴포넌트를 테스팅 하기에 충분합니다. Jest는 mocking [modules](/docs/testing-environments.html#mocking-modules)과 [timers](/docs/testing-environments.html#mocking-timers) 같은 파워풀한 특징과 결합되어 훌륭한 반복속도를 제공합니다. 그래서 더 많은 코드 제어를 가집니다. **[React Testing Library](https://testing-library.com/react)**는 실행 디테일을 가지지 않는 React 컴포넌트를 테스트하게 하는 도구 모음입니다. 이러한 접근은 리팩 토링을 수월하게 하며 접근성에 대한 가장 좋은 연습을 가능하게 합니다. 자식 컴포넌트를 가지지 않는 컴포넌트에 대한 얕은 렌더링 방법을 제공하지 않더라도 Jest와 같은 테스트 러너는 [mocking](/docs/testing-recipes.html#mocking-modules)에 의해 위를 가능하게 합니다. ### 더 보기 {#learn-more} + 두 개의 페이지로 나누어 저 있습니다. + - [Recipes](/docs/testing-recipes.html): React 컴포넌트에 대한 테스트를 작성할 때 흔한 패턴 - [Environments](/docs/testing-environments.html): React 컴포넌트에 대한 테스팅 환경을 설정할 때 고려해야 할 것 From cad34383e0e43b70347ed071080dea1a72e9e62e Mon Sep 17 00:00:00 2001 From: koDaegon Date: Tue, 5 Nov 2019 10:43:17 +0900 Subject: [PATCH 5/5] Update translation after review --- content/docs/testing.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/docs/testing.md b/content/docs/testing.md index ff4a905da..7a228d43d 100644 --- a/content/docs/testing.md +++ b/content/docs/testing.md @@ -16,7 +16,7 @@ React 컴포넌트를 테스트할 수 있는 몇 가지 방법이 있는데 크 이 문서 섹션은 아주 기본 테스팅 전략에 초점을 맞추고 있습니다. 풀 엔드투엔드 테스트는 중요한 워크플로의 퇴행을 방지하기 위해 매우 유용하지만 이러한 테스트들은 특정한 React 컴포넌트와 관련되어 있지 않습니다. 그리고 이들은 이 세션의 범위를 벗어납니다. -### 트레이드오프 {#tradeoffs} ? 상호교환 +### 트레이드오프 {#tradeoffs} 테스팅 도구를 선택할 때 몇 가지 트레이드오프를 생각하는 것은 의미 있는 일입니다. @@ -26,15 +26,15 @@ React 컴포넌트를 테스트할 수 있는 몇 가지 방법이 있는데 크 각각의 팀과 제품에 따라 다른 답이 적용될 수 있습니다. -### 추천 방법 {#tools} +### 추천 도구 {#tools} **[Jest](https://facebook.github.io/jest/)**는 JavaScript 테스트 러너입니다. DOM에 접근하게 하는 [`jsdom`](/docs/testing-environments.html#mocking-a-rendering-surface)을 통해서 jsdom은 단지 어떻게 브라우저가 작동하는지에 대한 대략적 개요입니다. 하지만 이는 종종 React 컴포넌트를 테스팅 하기에 충분합니다. Jest는 mocking [modules](/docs/testing-environments.html#mocking-modules)과 [timers](/docs/testing-environments.html#mocking-timers) 같은 파워풀한 특징과 결합되어 훌륭한 반복속도를 제공합니다. 그래서 더 많은 코드 제어를 가집니다. **[React Testing Library](https://testing-library.com/react)**는 실행 디테일을 가지지 않는 React 컴포넌트를 테스트하게 하는 도구 모음입니다. 이러한 접근은 리팩 토링을 수월하게 하며 접근성에 대한 가장 좋은 연습을 가능하게 합니다. 자식 컴포넌트를 가지지 않는 컴포넌트에 대한 얕은 렌더링 방법을 제공하지 않더라도 Jest와 같은 테스트 러너는 [mocking](/docs/testing-recipes.html#mocking-modules)에 의해 위를 가능하게 합니다. -### 더 보기 {#learn-more} +### 더 학습하기 {#learn-more} -두 개의 페이지로 나누어 저 있습니다. +두 개의 페이지로 나뉘어 있습니다. - [Recipes](/docs/testing-recipes.html): React 컴포넌트에 대한 테스트를 작성할 때 흔한 패턴 - [Environments](/docs/testing-environments.html): React 컴포넌트에 대한 테스팅 환경을 설정할 때 고려해야 할 것