From 7015789996a988746dd835ec4fcecc48679094a7 Mon Sep 17 00:00:00 2001 From: BeomYoung <50603295+BeomYoung@users.noreply.github.com> Date: Sat, 2 Nov 2019 11:20:04 +0900 Subject: [PATCH 01/16] Update testing-environments.md --- content/docs/testing-environments.md | 1 + 1 file changed, 1 insertion(+) diff --git a/content/docs/testing-environments.md b/content/docs/testing-environments.md index 5120a4f6d..52c55b76c 100644 --- a/content/docs/testing-environments.md +++ b/content/docs/testing-environments.md @@ -8,6 +8,7 @@ prev: testing-recipes.html This document goes through the factors that can affect your environment and recommendations for some scenarios. +이 문서는 환경에 영향을 줄 수 있는 요소와 일부 시나리오에 대한 권장 사항을 살펴본다. ### Test runners {#test-runners} From 5c2a18dc1d62431e49ade8d633d7888973adb0d0 Mon Sep 17 00:00:00 2001 From: BeomYoung <50603295+BeomYoung@users.noreply.github.com> Date: Sat, 2 Nov 2019 11:43:03 +0900 Subject: [PATCH 02/16] Update testing-environments.md --- content/docs/testing-environments.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/content/docs/testing-environments.md b/content/docs/testing-environments.md index 52c55b76c..ab4770bb2 100644 --- a/content/docs/testing-environments.md +++ b/content/docs/testing-environments.md @@ -8,12 +8,15 @@ prev: testing-recipes.html This document goes through the factors that can affect your environment and recommendations for some scenarios. + 이 문서는 환경에 영향을 줄 수 있는 요소와 일부 시나리오에 대한 권장 사항을 살펴본다. ### Test runners {#test-runners} Test runners like [Jest](https://jestjs.io/), [mocha](https://mochajs.org/), [ava](https://github.com/avajs/ava) let you write test suites as regular JavaScript, and run them as part of your development process. Additionally, test suites are run as part of continuous integration. +Jest, Mocha, ava와 같은 테스트 러너는 테스트 스위트를 일반 자바 스크립트로 작성하고, 개발 프로세스의 일부로 실행할 수 있도록 한다. 추가적으로, 테스트 스위트는 지속적 통합의 일부로 실행된다. + - Jest is widely compatible with React projects, supporting features like mocked [modules](#mocking-modules) and [timers](#mocking-timers), and [`jsdom`](#mocking-a-rendering-surface) support. **If you use Create React App, [Jest is already included out of the box](https://facebook.github.io/create-react-app/docs/running-tests) with useful defaults.** - Libraries like [mocha](https://mochajs.org/#running-mocha-in-the-browser) work well in real browser environments, and could help for tests that explicitly need it. - End-to-end tests are used for testing longer flows across multiple pages, and require a [different setup](#end-to-end-tests-aka-e2e-tests). From c0d3a3845b0021fe69a61298f9320906f45dabbe Mon Sep 17 00:00:00 2001 From: BeomYoung <50603295+BeomYoung@users.noreply.github.com> Date: Mon, 4 Nov 2019 14:48:34 +0900 Subject: [PATCH 03/16] Update testing-environments.md --- content/docs/testing-environments.md | 22 +++++++++++++++++++++- 1 file changed, 21 insertions(+), 1 deletion(-) diff --git a/content/docs/testing-environments.md b/content/docs/testing-environments.md index ab4770bb2..b4af4efd2 100644 --- a/content/docs/testing-environments.md +++ b/content/docs/testing-environments.md @@ -18,14 +18,34 @@ Test runners like [Jest](https://jestjs.io/), [mocha](https://mochajs.org/), [av Jest, Mocha, ava와 같은 테스트 러너는 테스트 스위트를 일반 자바 스크립트로 작성하고, 개발 프로세스의 일부로 실행할 수 있도록 한다. 추가적으로, 테스트 스위트는 지속적 통합의 일부로 실행된다. - Jest is widely compatible with React projects, supporting features like mocked [modules](#mocking-modules) and [timers](#mocking-timers), and [`jsdom`](#mocking-a-rendering-surface) support. **If you use Create React App, [Jest is already included out of the box](https://facebook.github.io/create-react-app/docs/running-tests) with useful defaults.** + +Jest는 모의 모듈 및 타이머, 그리고 jsdom 지원 등의 특징을 지원하는 리액트 프로젝트와 광범위하게 호환된다. + - Libraries like [mocha](https://mochajs.org/#running-mocha-in-the-browser) work well in real browser environments, and could help for tests that explicitly need it. + +mocha같은 라이브러리들은 실제 브라우저 환경에서 작동되며, 이는 분명히 필요한 테스트에 도움이 될 수 있다. + - End-to-end tests are used for testing longer flows across multiple pages, and require a [different setup](#end-to-end-tests-aka-e2e-tests). +엔드 투 엔드 테스트는 여러 페이지에 걸친 긴 흐름을 테스트하기 위해 사용되며, 다른 설정이 필요하다. + ### Mocking a rendering surface {#mocking-a-rendering-surface} Tests often run in an environment without access to a real rendering surface like a browser. For these environments, we recommend simulating a browser with [`jsdom`](https://github.com/jsdom/jsdom), a lightweight browser implementation that runs inside Node.js. -In most cases, jsdom behaves like a regular browser would, but doesn't have features like [layout and navigation](https://github.com/jsdom/jsdom#unimplemented-parts-of-the-web-platform). This is still useful for most web-based component tests, since it runs quicker than having to start up a browser for each test. It also runs in the same process as your tests, so you can write code to examine and assert on the rendered DOM. +테스트는 종종 브라우저와 같은 실제 렌더링 표면에 접근하지 않은 환경에서도 진행된다. 이런 환경에서는, Node.js 내에서 실행되는 가벼운 브라우저인 jsdom을 사용하여 브라우저를 시뮬레이션하는 것을 권장한다. + +In most cases, jsdom behaves like a regular browser would, but doesn't have features like [layout and navigation](https://github.com/jsdom/jsdom#unimplemented-parts-of-the-web-platform). + +대체로, jsdom은 일반 브라우저처럼 동작하지만 레이아웃이나 탐색과 같은 기능은 가지고 있지 않다. + +This is still useful for most web-based component tests, since it runs quicker than having to start up a browser for each test. + +이는 여전히 대부분의 웹 기반 구성 요소 테스트에 유용하다. 왜냐하면 테스트를 위해 브라우저를 시작하는 것보다 빨리 실행되기 때문이다. + +It also runs in the same process as your tests, so you can write code to examine and assert on the rendered DOM. + +또한 테스트와 동일한 프로세스에서 실행되므로, 렌더링된 DOM을 검토하고 확신할 코드를 작성할 수 있다. Just like in a real browser, jsdom lets us model user interactions; tests can dispatch events on DOM nodes, and then observe and assert on the side effects of these actions [(example)](/docs/testing-recipes.html#events). From 3e683b0e22c6ef32e801b638b6bcc746279d9d40 Mon Sep 17 00:00:00 2001 From: BeomYoung <50603295+BeomYoung@users.noreply.github.com> Date: Tue, 5 Nov 2019 01:37:43 +0900 Subject: [PATCH 04/16] Update testing-environments.md --- content/docs/testing-environments.md | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-) diff --git a/content/docs/testing-environments.md b/content/docs/testing-environments.md index b4af4efd2..77d3ba3db 100644 --- a/content/docs/testing-environments.md +++ b/content/docs/testing-environments.md @@ -41,7 +41,7 @@ In most cases, jsdom behaves like a regular browser would, but doesn't have feat This is still useful for most web-based component tests, since it runs quicker than having to start up a browser for each test. -이는 여전히 대부분의 웹 기반 구성 요소 테스트에 유용하다. 왜냐하면 테스트를 위해 브라우저를 시작하는 것보다 빨리 실행되기 때문이다. +이는 여전히 대부분의 웹 기반 컴포넌트 테스트에 유용하다. 왜냐하면 테스트를 위해 브라우저를 시작하는 것보다 빨리 실행되기 때문이다. It also runs in the same process as your tests, so you can write code to examine and assert on the rendered DOM. @@ -49,17 +49,31 @@ It also runs in the same process as your tests, so you can write code to examine Just like in a real browser, jsdom lets us model user interactions; tests can dispatch events on DOM nodes, and then observe and assert on the side effects of these actions [(example)](/docs/testing-recipes.html#events). +실제 브라우저와 마찬가지로, jsdom은 사용자 상호작용을 모델링할 수 있도록 한다. 테스트는 DOM 노드에서 이벤트를 발송한 다음 이러한 동작의 부작용을 관찰하고 주장할 수 있다.(예시) + A large portion of UI tests can be written with the above setup: using Jest as a test runner, rendered to jsdom, with user interactions specified as sequences of browser events, powered by the `act()` helper [(example)](/docs/testing-recipes.html). For example, a lot of React's own tests are written with this combination. +UI 테스트의 많은 부분은 위의 설정으로 작성할 수 있다. jsdom에게 렌더링하는 테스트 러너로서, 브라우저 이벤트 시퀀스로 지정된 사용자 상호작용과 함께Jest를 사용하는 것은 act() 도우미에 의해 작동된다.(예시) 예를 들어, 많은 리액트 자체 테스트는 이런 조합으로 작성된다. + If you're writing a library that tests mostly browser-specific behavior, and requires native browser behavior like layout or real inputs, you could use a framework like [mocha.](https://mochajs.org/) +만약 대부분의 브라우저별 동작을 테스트하고 레이아웃이나 실제 입력과 같은 네이티브 브라우저 동작을 요구하는 라이브러리를 작성하는 경우 mocha와 같은 프레임 워크를 사용할 수 있다. + In an environment where you _can't_ simulate a DOM (e.g. testing React Native components on Node.js), you could use [event simulation helpers](https://reactjs.org/docs/test-utils.html#simulate) to simulate interactions with elements. Alternately, you could use the `fireEvent` helper from [`@testing-library/react-native`](https://testing-library.com/docs/native-testing-library). +DOM을 시뮬레이션할 수 없는 환경에서 (예를 들면, Node.js리에서의 리액트 네이티브 컴포넌트 테스트), 엘리먼트와의 상호작용을 시뮬레이션하기 위해 event simulation helpers 를 사용할 수 있다. + Frameworks like [Cypress](https://www.cypress.io/), [puppeteer](https://github.com/GoogleChrome/puppeteer) and [webdriver](https://www.seleniumhq.org/projects/webdriver/) are useful for running [end-to-end tests](#end-to-end-tests-aka-e2e-tests). +Cypress, puppeteer, webdriver 같은 프레임워크들은 end-to-end 테스트를 진행하기에 유용하다. + ### Mocking functions {#mocking-functions} -When writing tests, we'd like to mock out the parts of our code that don't have equivalents inside our testing environment (e.g. checking `navigator.onLine` status inside Node.js). Tests could also spy on some functions, and observe how other parts of the test interact with them. It is then useful to be able to selectively mock these functions with test-friendly versions. +### 모의 함수 + +When writing tests, we'd like to mock out the parts of our code that don't have equivalents inside our testing environment (e.g. checking `navigator.onLine` status inside Node.js). Tests could also spy on some functions, and observe how other parts of the test interact with them. It is then useful to be able to selectively mock these functions with test-friendly versions. + +테스트를 작성할 때, 우리는 테스트 환경 내부에서 동등성이 없는 우리의 코드 중 일부를 목아웃하고 싶다(예를 들어, navigator.online상태를 Node.js 내부에서 확인하는 것처럼). 테스트는 또한 일부 함수를 감시할 수 있으며 테스트의 다른 부분이 함수들과 어떻게 상호작용하는지를 관찰할 수 있다. 이는 이러한 함수들을 선택적으로 시험 친화적인 버전으로 모의할 수 있다는 점에서 유용하다. This is especially useful for data fetching. It is usually preferable to use "fake" data for tests to avoid the slowness and flakiness due to fetching from real API endpoints [(example)](/docs/testing-recipes.html#data-fetching). This helps make the tests predictable. Libraries like [Jest](https://jestjs.io/) and [sinon](https://sinonjs.org/), among others, support mocked functions. For end-to-end tests, mocking network can be more difficult, but you might also want to test the real API endpoints in them anyway. From b643cef43bc693fe18254fa4b2b218f73e4ec2a4 Mon Sep 17 00:00:00 2001 From: BeomYoung <50603295+BeomYoung@users.noreply.github.com> Date: Tue, 5 Nov 2019 14:15:19 +0900 Subject: [PATCH 05/16] Update testing-environments.md --- content/docs/testing-environments.md | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/content/docs/testing-environments.md b/content/docs/testing-environments.md index 77d3ba3db..e33d596cf 100644 --- a/content/docs/testing-environments.md +++ b/content/docs/testing-environments.md @@ -11,7 +11,7 @@ This document goes through the factors that can affect your environment and reco 이 문서는 환경에 영향을 줄 수 있는 요소와 일부 시나리오에 대한 권장 사항을 살펴본다. -### Test runners {#test-runners} +### Tests {#test-runners} Test runners like [Jest](https://jestjs.io/), [mocha](https://mochajs.org/), [ava](https://github.com/avajs/ava) let you write test suites as regular JavaScript, and run them as part of your development process. Additionally, test suites are run as part of continuous integration. @@ -77,16 +77,28 @@ When writing tests, we'd like to mock out the parts of our code that don't have This is especially useful for data fetching. It is usually preferable to use "fake" data for tests to avoid the slowness and flakiness due to fetching from real API endpoints [(example)](/docs/testing-recipes.html#data-fetching). This helps make the tests predictable. Libraries like [Jest](https://jestjs.io/) and [sinon](https://sinonjs.org/), among others, support mocked functions. For end-to-end tests, mocking network can be more difficult, but you might also want to test the real API endpoints in them anyway. +모의함수는 특히 데이터 패칭에 유용하다. 실제 API 종단점으로부터 발생하는 느려짐과 손상을 방지하기 위해 테스트에 "가짜"데이터를 사용하는 것이 바람직하다. 이는 테스트를 예측 가능하게 만들어준다. Jest와 sinon과 같은 라이브러리들은 모의 함수들을 지원한다. 엔드 투 엔드 테스트의 경우, 모의 네트워크가 더 어려울 수 있지만, 그것들의 실제 API 엔드포인트를 테스트하기를 원할 수도 있다. + ### Mocking modules {#mocking-modules} +### 모의 모듈 + Some components have dependencies for modules that may not work well in test environments, or aren't essential to our tests. It can be useful to selectively mock these modules out with suitable replacements [(example)](/docs/testing-recipes.html#mocking-modules). +일부 컴포넌트는 테스트 환경에서 잘 작동하지 않거나 테스트에 필수적이지 않은 모듈에 대한 의존성을 가지고 있다. 적절한 교체를 통해 이러한 모듈을 선택적으로 모의하는 것이 유용할 수 있다. + On Node.js, runners like Jest [support mocking modules](https://jestjs.io/docs/en/manual-mocks). You could also use libraries like [`mock-require`](https://www.npmjs.com/package/mock-require). +Node.js에서 Jest같은 러너는 모의 모듈을 지원한다. 또한 mock-require 라이브러리도 사용할 수 있다. + ### Mocking timers {#mocking-timers} +### 모의 타이머 + Components might be using time-based functions like `setTimeout`, `setInterval`, or `Date.now`. In testing environments, it can be helpful to mock these functions out with replacements that let you manually "advance" time. This is great for making sure your tests run fast! Tests that are dependent on timers would still resolve in order, but quicker [(example)](/docs/testing-recipes.html#timers). Most frameworks, including [Jest](https://jestjs.io/docs/en/timer-mocks), [sinon](https://sinonjs.org/releases/v7.3.2/fake-timers/) and [lolex](https://github.com/sinonjs/lolex), let you mock timers in your tests. +컴포넌트는 setTimeout, setInterval, Data.now와 같은 시간을 기반으로한 함수를 사용할 수 있다. 테스트 환경에서, 이러한 함수들을 수동으로 발전할 수 있는 대체품으로 모의하는 것이 유용할 수 있다. + Sometimes, you may not want to mock timers. For example, maybe you're testing an animation, or interacting with an endpoint that's sensitive to timing (like an API rate limiter). Libraries with timer mocks let you enable and disable them on a per test/suite basis, so you can explicitly choose how these tests would run. ### End-to-end tests {#end-to-end-tests-aka-e2e-tests} From 94f869271525323ee590ea925c661d7f347d18f0 Mon Sep 17 00:00:00 2001 From: BeomYoung <50603295+BeomYoung@users.noreply.github.com> Date: Wed, 6 Nov 2019 13:43:01 +0900 Subject: [PATCH 06/16] Update testing-environments.md --- content/docs/testing-environments.md | 20 ++++++++++++++++---- 1 file changed, 16 insertions(+), 4 deletions(-) diff --git a/content/docs/testing-environments.md b/content/docs/testing-environments.md index e33d596cf..e7eec22a8 100644 --- a/content/docs/testing-environments.md +++ b/content/docs/testing-environments.md @@ -13,6 +13,8 @@ This document goes through the factors that can affect your environment and reco ### Tests {#test-runners} +### 테스트 {#테스트 러너} + Test runners like [Jest](https://jestjs.io/), [mocha](https://mochajs.org/), [ava](https://github.com/avajs/ava) let you write test suites as regular JavaScript, and run them as part of your development process. Additionally, test suites are run as part of continuous integration. Jest, Mocha, ava와 같은 테스트 러너는 테스트 스위트를 일반 자바 스크립트로 작성하고, 개발 프로세스의 일부로 실행할 수 있도록 한다. 추가적으로, 테스트 스위트는 지속적 통합의 일부로 실행된다. @@ -31,6 +33,8 @@ mocha같은 라이브러리들은 실제 브라우저 환경에서 작동되며, ### Mocking a rendering surface {#mocking-a-rendering-surface} +### 렌더링 표면에 대한 모의 {#렌더링-표면에-대한-모의} + Tests often run in an environment without access to a real rendering surface like a browser. For these environments, we recommend simulating a browser with [`jsdom`](https://github.com/jsdom/jsdom), a lightweight browser implementation that runs inside Node.js. 테스트는 종종 브라우저와 같은 실제 렌더링 표면에 접근하지 않은 환경에서도 진행된다. 이런 환경에서는, Node.js 내에서 실행되는 가벼운 브라우저인 jsdom을 사용하여 브라우저를 시뮬레이션하는 것을 권장한다. @@ -69,7 +73,7 @@ Cypress, puppeteer, webdriver 같은 프레임워크들은 end-to-end 테스트 ### Mocking functions {#mocking-functions} -### 모의 함수 +### 모의 함수 {#모의-함수} When writing tests, we'd like to mock out the parts of our code that don't have equivalents inside our testing environment (e.g. checking `navigator.onLine` status inside Node.js). Tests could also spy on some functions, and observe how other parts of the test interact with them. It is then useful to be able to selectively mock these functions with test-friendly versions. @@ -81,7 +85,7 @@ This is especially useful for data fetching. It is usually preferable to use "fa ### Mocking modules {#mocking-modules} -### 모의 모듈 +### 모의 모듈 {#모의-모듈} Some components have dependencies for modules that may not work well in test environments, or aren't essential to our tests. It can be useful to selectively mock these modules out with suitable replacements [(example)](/docs/testing-recipes.html#mocking-modules). @@ -93,16 +97,24 @@ Node.js에서 Jest같은 러너는 모의 모듈을 지원한다. 또한 mock-re ### Mocking timers {#mocking-timers} -### 모의 타이머 +### 모의 타이머 {#모의-타이머} Components might be using time-based functions like `setTimeout`, `setInterval`, or `Date.now`. In testing environments, it can be helpful to mock these functions out with replacements that let you manually "advance" time. This is great for making sure your tests run fast! Tests that are dependent on timers would still resolve in order, but quicker [(example)](/docs/testing-recipes.html#timers). Most frameworks, including [Jest](https://jestjs.io/docs/en/timer-mocks), [sinon](https://sinonjs.org/releases/v7.3.2/fake-timers/) and [lolex](https://github.com/sinonjs/lolex), let you mock timers in your tests. -컴포넌트는 setTimeout, setInterval, Data.now와 같은 시간을 기반으로한 함수를 사용할 수 있다. 테스트 환경에서, 이러한 함수들을 수동으로 발전할 수 있는 대체품으로 모의하는 것이 유용할 수 있다. +컴포넌트는 setTimeout, setInterval, Data.now와 같은 시간을 기반으로한 함수를 사용할 수 있다. 테스트 환경에서, 이러한 함수들을 수동으로 발전할 수 있는 대체품으로 모의하는 것이 유용할 수 있다. 이것은 테스트가 빨리 진행되도록 하는 데 좋다! 타이머에 의존하는 테스트는 여전히 순서대로 해결되지만 더 빨리 해결된다(예시). Jest, sinon, lolex를 포함한 대부분의 프레임워크는 테스트에서 타이머를 모의할 수 있게 해준다. Sometimes, you may not want to mock timers. For example, maybe you're testing an animation, or interacting with an endpoint that's sensitive to timing (like an API rate limiter). Libraries with timer mocks let you enable and disable them on a per test/suite basis, so you can explicitly choose how these tests would run. +가끔, 모의 타이머를 원하지 않는 경우가 있을 수 있다. 예를 들어, 애니메이션을 테스트하거나, 또는 (API 속도 제한 장치와 같은) 타이밍에 민감한 종단점과의 상호작용을 하는 경우가 있다. 타이머 모의가 있는 라이브러리는 테스트/묶음별로 활성화 및 비활성화할 수 있으므로 이러한 테스트 실행 방법을 명시적으로 선택할 수 있다. + ### End-to-end tests {#end-to-end-tests-aka-e2e-tests} +### 엔드 투 엔드 테스트 {#엔드-투-엔드-테스트( + End-to-end tests are useful for testing longer workflows, especially when they're critical to your business (such as payments or signups). For these tests, you'd probably want to test both how a real browser renders the whole app, fetches data from the real API endpoints, uses sessions and cookies, navigates between different links. You might also likely want to make assertions not just on the DOM state, but on the backing data as well (e.g. to verify whether the updates have been persisted to the database). +엔드 투 엔드 테스트는 더 긴 작업흐름을 테스트하는 데 유용하며, 특히 비즈니스에 중요한 작업흐름(결제 또는 등록과 같은)을 테스트하는 데 유용하다. 이러한 경우, 실제 앱 전체를 렌더링하고, 실제 API 종단점에서 데이터를 가져오고, 세션과 쿠키를 사용하며, 다른 링크 사이를 이동하는 방법을 모두 테스트 하기를 원할 것이다. 또한 DOM 상태뿐만 아니라 백업 데이터(예를 들어, 업데이트가 데이터베이스에 유지되었는지 확인하기 위해)에 대해서도 주장하기를 원할 수 있다. + In this scenario, you would use a framework like [Cypress](https://www.cypress.io/) or a library like [puppeteer](https://github.com/GoogleChrome/puppeteer) so you can navigate between multiple routes and assert on side effects not just in the browser, but potentially on the backend as well. + +이러한 시나리오에서는 Cypress와 같은 프레임워크나 puppeteer 같은 라이브러리를 사용하여 여러 경로를 탐색하고 브라우저뿐만 아니라 잠재적으로 백엔드에서도 부작용에 대해 주장할 수 있다. From 145271d2dc098328822908c344d8fdd056f9c8e5 Mon Sep 17 00:00:00 2001 From: BeomYoung <50603295+BeomYoung@users.noreply.github.com> Date: Wed, 6 Nov 2019 15:04:12 +0900 Subject: [PATCH 07/16] Update testing-environments.md --- content/docs/testing-environments.md | 51 +--------------------------- 1 file changed, 1 insertion(+), 50 deletions(-) diff --git a/content/docs/testing-environments.md b/content/docs/testing-environments.md index e7eec22a8..c74ff8b98 100644 --- a/content/docs/testing-environments.md +++ b/content/docs/testing-environments.md @@ -7,114 +7,65 @@ prev: testing-recipes.html -This document goes through the factors that can affect your environment and recommendations for some scenarios. - 이 문서는 환경에 영향을 줄 수 있는 요소와 일부 시나리오에 대한 권장 사항을 살펴본다. -### Tests {#test-runners} ### 테스트 {#테스트 러너} -Test runners like [Jest](https://jestjs.io/), [mocha](https://mochajs.org/), [ava](https://github.com/avajs/ava) let you write test suites as regular JavaScript, and run them as part of your development process. Additionally, test suites are run as part of continuous integration. - Jest, Mocha, ava와 같은 테스트 러너는 테스트 스위트를 일반 자바 스크립트로 작성하고, 개발 프로세스의 일부로 실행할 수 있도록 한다. 추가적으로, 테스트 스위트는 지속적 통합의 일부로 실행된다. -- Jest is widely compatible with React projects, supporting features like mocked [modules](#mocking-modules) and [timers](#mocking-timers), and [`jsdom`](#mocking-a-rendering-surface) support. **If you use Create React App, [Jest is already included out of the box](https://facebook.github.io/create-react-app/docs/running-tests) with useful defaults.** - -Jest는 모의 모듈 및 타이머, 그리고 jsdom 지원 등의 특징을 지원하는 리액트 프로젝트와 광범위하게 호환된다. - -- Libraries like [mocha](https://mochajs.org/#running-mocha-in-the-browser) work well in real browser environments, and could help for tests that explicitly need it. +Jest는 모의 모듈 및 타이머, 그리고 jsdom 지원 등의 특징을 지원하는 리액트 프로젝트와 광범위하게 호환된다. 만약 리액트 어플을 만들 때, Jest는 이미 유용한 값으로 박스에 포함되어 있다. mocha같은 라이브러리들은 실제 브라우저 환경에서 작동되며, 이는 분명히 필요한 테스트에 도움이 될 수 있다. -- End-to-end tests are used for testing longer flows across multiple pages, and require a [different setup](#end-to-end-tests-aka-e2e-tests). - 엔드 투 엔드 테스트는 여러 페이지에 걸친 긴 흐름을 테스트하기 위해 사용되며, 다른 설정이 필요하다. -### Mocking a rendering surface {#mocking-a-rendering-surface} ### 렌더링 표면에 대한 모의 {#렌더링-표면에-대한-모의} -Tests often run in an environment without access to a real rendering surface like a browser. For these environments, we recommend simulating a browser with [`jsdom`](https://github.com/jsdom/jsdom), a lightweight browser implementation that runs inside Node.js. - 테스트는 종종 브라우저와 같은 실제 렌더링 표면에 접근하지 않은 환경에서도 진행된다. 이런 환경에서는, Node.js 내에서 실행되는 가벼운 브라우저인 jsdom을 사용하여 브라우저를 시뮬레이션하는 것을 권장한다. -In most cases, jsdom behaves like a regular browser would, but doesn't have features like [layout and navigation](https://github.com/jsdom/jsdom#unimplemented-parts-of-the-web-platform). - 대체로, jsdom은 일반 브라우저처럼 동작하지만 레이아웃이나 탐색과 같은 기능은 가지고 있지 않다. -This is still useful for most web-based component tests, since it runs quicker than having to start up a browser for each test. - 이는 여전히 대부분의 웹 기반 컴포넌트 테스트에 유용하다. 왜냐하면 테스트를 위해 브라우저를 시작하는 것보다 빨리 실행되기 때문이다. -It also runs in the same process as your tests, so you can write code to examine and assert on the rendered DOM. - 또한 테스트와 동일한 프로세스에서 실행되므로, 렌더링된 DOM을 검토하고 확신할 코드를 작성할 수 있다. -Just like in a real browser, jsdom lets us model user interactions; tests can dispatch events on DOM nodes, and then observe and assert on the side effects of these actions [(example)](/docs/testing-recipes.html#events). - 실제 브라우저와 마찬가지로, jsdom은 사용자 상호작용을 모델링할 수 있도록 한다. 테스트는 DOM 노드에서 이벤트를 발송한 다음 이러한 동작의 부작용을 관찰하고 주장할 수 있다.(예시) -A large portion of UI tests can be written with the above setup: using Jest as a test runner, rendered to jsdom, with user interactions specified as sequences of browser events, powered by the `act()` helper [(example)](/docs/testing-recipes.html). For example, a lot of React's own tests are written with this combination. - UI 테스트의 많은 부분은 위의 설정으로 작성할 수 있다. jsdom에게 렌더링하는 테스트 러너로서, 브라우저 이벤트 시퀀스로 지정된 사용자 상호작용과 함께Jest를 사용하는 것은 act() 도우미에 의해 작동된다.(예시) 예를 들어, 많은 리액트 자체 테스트는 이런 조합으로 작성된다. -If you're writing a library that tests mostly browser-specific behavior, and requires native browser behavior like layout or real inputs, you could use a framework like [mocha.](https://mochajs.org/) - 만약 대부분의 브라우저별 동작을 테스트하고 레이아웃이나 실제 입력과 같은 네이티브 브라우저 동작을 요구하는 라이브러리를 작성하는 경우 mocha와 같은 프레임 워크를 사용할 수 있다. -In an environment where you _can't_ simulate a DOM (e.g. testing React Native components on Node.js), you could use [event simulation helpers](https://reactjs.org/docs/test-utils.html#simulate) to simulate interactions with elements. Alternately, you could use the `fireEvent` helper from [`@testing-library/react-native`](https://testing-library.com/docs/native-testing-library). - DOM을 시뮬레이션할 수 없는 환경에서 (예를 들면, Node.js리에서의 리액트 네이티브 컴포넌트 테스트), 엘리먼트와의 상호작용을 시뮬레이션하기 위해 event simulation helpers 를 사용할 수 있다. -Frameworks like [Cypress](https://www.cypress.io/), [puppeteer](https://github.com/GoogleChrome/puppeteer) and [webdriver](https://www.seleniumhq.org/projects/webdriver/) are useful for running [end-to-end tests](#end-to-end-tests-aka-e2e-tests). - Cypress, puppeteer, webdriver 같은 프레임워크들은 end-to-end 테스트를 진행하기에 유용하다. -### Mocking functions {#mocking-functions} ### 모의 함수 {#모의-함수} -When writing tests, we'd like to mock out the parts of our code that don't have equivalents inside our testing environment (e.g. checking `navigator.onLine` status inside Node.js). Tests could also spy on some functions, and observe how other parts of the test interact with them. It is then useful to be able to selectively mock these functions with test-friendly versions. - 테스트를 작성할 때, 우리는 테스트 환경 내부에서 동등성이 없는 우리의 코드 중 일부를 목아웃하고 싶다(예를 들어, navigator.online상태를 Node.js 내부에서 확인하는 것처럼). 테스트는 또한 일부 함수를 감시할 수 있으며 테스트의 다른 부분이 함수들과 어떻게 상호작용하는지를 관찰할 수 있다. 이는 이러한 함수들을 선택적으로 시험 친화적인 버전으로 모의할 수 있다는 점에서 유용하다. -This is especially useful for data fetching. It is usually preferable to use "fake" data for tests to avoid the slowness and flakiness due to fetching from real API endpoints [(example)](/docs/testing-recipes.html#data-fetching). This helps make the tests predictable. Libraries like [Jest](https://jestjs.io/) and [sinon](https://sinonjs.org/), among others, support mocked functions. For end-to-end tests, mocking network can be more difficult, but you might also want to test the real API endpoints in them anyway. - 모의함수는 특히 데이터 패칭에 유용하다. 실제 API 종단점으로부터 발생하는 느려짐과 손상을 방지하기 위해 테스트에 "가짜"데이터를 사용하는 것이 바람직하다. 이는 테스트를 예측 가능하게 만들어준다. Jest와 sinon과 같은 라이브러리들은 모의 함수들을 지원한다. 엔드 투 엔드 테스트의 경우, 모의 네트워크가 더 어려울 수 있지만, 그것들의 실제 API 엔드포인트를 테스트하기를 원할 수도 있다. -### Mocking modules {#mocking-modules} ### 모의 모듈 {#모의-모듈} -Some components have dependencies for modules that may not work well in test environments, or aren't essential to our tests. It can be useful to selectively mock these modules out with suitable replacements [(example)](/docs/testing-recipes.html#mocking-modules). - 일부 컴포넌트는 테스트 환경에서 잘 작동하지 않거나 테스트에 필수적이지 않은 모듈에 대한 의존성을 가지고 있다. 적절한 교체를 통해 이러한 모듈을 선택적으로 모의하는 것이 유용할 수 있다. -On Node.js, runners like Jest [support mocking modules](https://jestjs.io/docs/en/manual-mocks). You could also use libraries like [`mock-require`](https://www.npmjs.com/package/mock-require). - Node.js에서 Jest같은 러너는 모의 모듈을 지원한다. 또한 mock-require 라이브러리도 사용할 수 있다. -### Mocking timers {#mocking-timers} ### 모의 타이머 {#모의-타이머} -Components might be using time-based functions like `setTimeout`, `setInterval`, or `Date.now`. In testing environments, it can be helpful to mock these functions out with replacements that let you manually "advance" time. This is great for making sure your tests run fast! Tests that are dependent on timers would still resolve in order, but quicker [(example)](/docs/testing-recipes.html#timers). Most frameworks, including [Jest](https://jestjs.io/docs/en/timer-mocks), [sinon](https://sinonjs.org/releases/v7.3.2/fake-timers/) and [lolex](https://github.com/sinonjs/lolex), let you mock timers in your tests. - 컴포넌트는 setTimeout, setInterval, Data.now와 같은 시간을 기반으로한 함수를 사용할 수 있다. 테스트 환경에서, 이러한 함수들을 수동으로 발전할 수 있는 대체품으로 모의하는 것이 유용할 수 있다. 이것은 테스트가 빨리 진행되도록 하는 데 좋다! 타이머에 의존하는 테스트는 여전히 순서대로 해결되지만 더 빨리 해결된다(예시). Jest, sinon, lolex를 포함한 대부분의 프레임워크는 테스트에서 타이머를 모의할 수 있게 해준다. -Sometimes, you may not want to mock timers. For example, maybe you're testing an animation, or interacting with an endpoint that's sensitive to timing (like an API rate limiter). Libraries with timer mocks let you enable and disable them on a per test/suite basis, so you can explicitly choose how these tests would run. - 가끔, 모의 타이머를 원하지 않는 경우가 있을 수 있다. 예를 들어, 애니메이션을 테스트하거나, 또는 (API 속도 제한 장치와 같은) 타이밍에 민감한 종단점과의 상호작용을 하는 경우가 있다. 타이머 모의가 있는 라이브러리는 테스트/묶음별로 활성화 및 비활성화할 수 있으므로 이러한 테스트 실행 방법을 명시적으로 선택할 수 있다. -### End-to-end tests {#end-to-end-tests-aka-e2e-tests} ### 엔드 투 엔드 테스트 {#엔드-투-엔드-테스트( -End-to-end tests are useful for testing longer workflows, especially when they're critical to your business (such as payments or signups). For these tests, you'd probably want to test both how a real browser renders the whole app, fetches data from the real API endpoints, uses sessions and cookies, navigates between different links. You might also likely want to make assertions not just on the DOM state, but on the backing data as well (e.g. to verify whether the updates have been persisted to the database). 엔드 투 엔드 테스트는 더 긴 작업흐름을 테스트하는 데 유용하며, 특히 비즈니스에 중요한 작업흐름(결제 또는 등록과 같은)을 테스트하는 데 유용하다. 이러한 경우, 실제 앱 전체를 렌더링하고, 실제 API 종단점에서 데이터를 가져오고, 세션과 쿠키를 사용하며, 다른 링크 사이를 이동하는 방법을 모두 테스트 하기를 원할 것이다. 또한 DOM 상태뿐만 아니라 백업 데이터(예를 들어, 업데이트가 데이터베이스에 유지되었는지 확인하기 위해)에 대해서도 주장하기를 원할 수 있다. -In this scenario, you would use a framework like [Cypress](https://www.cypress.io/) or a library like [puppeteer](https://github.com/GoogleChrome/puppeteer) so you can navigate between multiple routes and assert on side effects not just in the browser, but potentially on the backend as well. - 이러한 시나리오에서는 Cypress와 같은 프레임워크나 puppeteer 같은 라이브러리를 사용하여 여러 경로를 탐색하고 브라우저뿐만 아니라 잠재적으로 백엔드에서도 부작용에 대해 주장할 수 있다. From 9a483b647e799de56aca1f3c58a92edced709715 Mon Sep 17 00:00:00 2001 From: BeomYoung <50603295+BeomYoung@users.noreply.github.com> Date: Wed, 6 Nov 2019 15:04:51 +0900 Subject: [PATCH 08/16] Update testing-environments.md --- content/docs/testing-environments.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/testing-environments.md b/content/docs/testing-environments.md index c74ff8b98..0c08aee2f 100644 --- a/content/docs/testing-environments.md +++ b/content/docs/testing-environments.md @@ -63,7 +63,7 @@ Node.js에서 Jest같은 러너는 모의 모듈을 지원한다. 또한 mock-re 가끔, 모의 타이머를 원하지 않는 경우가 있을 수 있다. 예를 들어, 애니메이션을 테스트하거나, 또는 (API 속도 제한 장치와 같은) 타이밍에 민감한 종단점과의 상호작용을 하는 경우가 있다. 타이머 모의가 있는 라이브러리는 테스트/묶음별로 활성화 및 비활성화할 수 있으므로 이러한 테스트 실행 방법을 명시적으로 선택할 수 있다. -### 엔드 투 엔드 테스트 {#엔드-투-엔드-테스트( +### 엔드 투 엔드 테스트 {#엔드-투-엔드-테스트} 엔드 투 엔드 테스트는 더 긴 작업흐름을 테스트하는 데 유용하며, 특히 비즈니스에 중요한 작업흐름(결제 또는 등록과 같은)을 테스트하는 데 유용하다. 이러한 경우, 실제 앱 전체를 렌더링하고, 실제 API 종단점에서 데이터를 가져오고, 세션과 쿠키를 사용하며, 다른 링크 사이를 이동하는 방법을 모두 테스트 하기를 원할 것이다. 또한 DOM 상태뿐만 아니라 백업 데이터(예를 들어, 업데이트가 데이터베이스에 유지되었는지 확인하기 위해)에 대해서도 주장하기를 원할 수 있다. From 2754d4192a4981ff42729e3f202697b0030f1752 Mon Sep 17 00:00:00 2001 From: BeomYoung <50603295+BeomYoung@users.noreply.github.com> Date: Thu, 7 Nov 2019 13:48:18 +0900 Subject: [PATCH 09/16] Update testing-environments.md --- content/docs/testing-environments.md | 12 +----------- 1 file changed, 1 insertion(+), 11 deletions(-) diff --git a/content/docs/testing-environments.md b/content/docs/testing-environments.md index 0c08aee2f..59a95fb2a 100644 --- a/content/docs/testing-environments.md +++ b/content/docs/testing-environments.md @@ -9,27 +9,17 @@ prev: testing-recipes.html 이 문서는 환경에 영향을 줄 수 있는 요소와 일부 시나리오에 대한 권장 사항을 살펴본다. - ### 테스트 {#테스트 러너} Jest, Mocha, ava와 같은 테스트 러너는 테스트 스위트를 일반 자바 스크립트로 작성하고, 개발 프로세스의 일부로 실행할 수 있도록 한다. 추가적으로, 테스트 스위트는 지속적 통합의 일부로 실행된다. Jest는 모의 모듈 및 타이머, 그리고 jsdom 지원 등의 특징을 지원하는 리액트 프로젝트와 광범위하게 호환된다. 만약 리액트 어플을 만들 때, Jest는 이미 유용한 값으로 박스에 포함되어 있다. - mocha같은 라이브러리들은 실제 브라우저 환경에서 작동되며, 이는 분명히 필요한 테스트에 도움이 될 수 있다. - 엔드 투 엔드 테스트는 여러 페이지에 걸친 긴 흐름을 테스트하기 위해 사용되며, 다른 설정이 필요하다. - ### 렌더링 표면에 대한 모의 {#렌더링-표면에-대한-모의} -테스트는 종종 브라우저와 같은 실제 렌더링 표면에 접근하지 않은 환경에서도 진행된다. 이런 환경에서는, Node.js 내에서 실행되는 가벼운 브라우저인 jsdom을 사용하여 브라우저를 시뮬레이션하는 것을 권장한다. - -대체로, jsdom은 일반 브라우저처럼 동작하지만 레이아웃이나 탐색과 같은 기능은 가지고 있지 않다. - -이는 여전히 대부분의 웹 기반 컴포넌트 테스트에 유용하다. 왜냐하면 테스트를 위해 브라우저를 시작하는 것보다 빨리 실행되기 때문이다. - -또한 테스트와 동일한 프로세스에서 실행되므로, 렌더링된 DOM을 검토하고 확신할 코드를 작성할 수 있다. +테스트는 종종 브라우저와 같은 실제 렌더링 표면에 접근하지 않은 환경에서도 진행된다. 이런 환경에서는, Node.js 내에서 실행되는 가벼운 브라우저인 jsdom을 사용하여 브라우저를 시뮬레이션하는 것을 권장한다. 대체로, jsdom은 일반 브라우저처럼 동작하지만 레이아웃이나 탐색과 같은 기능은 가지고 있지 않다. 이는 여전히 대부분의 웹 기반 컴포넌트 테스트에 유용하다. 왜냐하면 테스트를 위해 브라우저를 시작하는 것보다 빨리 실행되기 때문이다. 또한 테스트와 동일한 프로세스에서 실행되므로, 렌더링된 DOM을 검토하고 확신할 코드를 작성할 수 있다. 실제 브라우저와 마찬가지로, jsdom은 사용자 상호작용을 모델링할 수 있도록 한다. 테스트는 DOM 노드에서 이벤트를 발송한 다음 이러한 동작의 부작용을 관찰하고 주장할 수 있다.(예시) From b0f17b3a2b4ec6237b1d3726e1e51fb605993076 Mon Sep 17 00:00:00 2001 From: BeomYoung <50603295+BeomYoung@users.noreply.github.com> Date: Thu, 7 Nov 2019 13:50:24 +0900 Subject: [PATCH 10/16] Update testing-environments.md --- content/docs/testing-environments.md | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/content/docs/testing-environments.md b/content/docs/testing-environments.md index 59a95fb2a..51a67cf64 100644 --- a/content/docs/testing-environments.md +++ b/content/docs/testing-environments.md @@ -19,7 +19,9 @@ mocha같은 라이브러리들은 실제 브라우저 환경에서 작동되며, ### 렌더링 표면에 대한 모의 {#렌더링-표면에-대한-모의} -테스트는 종종 브라우저와 같은 실제 렌더링 표면에 접근하지 않은 환경에서도 진행된다. 이런 환경에서는, Node.js 내에서 실행되는 가벼운 브라우저인 jsdom을 사용하여 브라우저를 시뮬레이션하는 것을 권장한다. 대체로, jsdom은 일반 브라우저처럼 동작하지만 레이아웃이나 탐색과 같은 기능은 가지고 있지 않다. 이는 여전히 대부분의 웹 기반 컴포넌트 테스트에 유용하다. 왜냐하면 테스트를 위해 브라우저를 시작하는 것보다 빨리 실행되기 때문이다. 또한 테스트와 동일한 프로세스에서 실행되므로, 렌더링된 DOM을 검토하고 확신할 코드를 작성할 수 있다. +테스트는 종종 브라우저와 같은 실제 렌더링 표면에 접근하지 않은 환경에서도 진행된다. 이런 환경에서는, Node.js 내에서 실행되는 가벼운 브라우저인 jsdom을 사용하여 브라우저를 시뮬레이션하는 것을 권장한다. + +대체로, jsdom은 일반 브라우저처럼 동작하지만 레이아웃이나 탐색과 같은 기능은 가지고 있지 않다. 이는 여전히 대부분의 웹 기반 컴포넌트 테스트에 유용하다. 왜냐하면 테스트를 위해 브라우저를 시작하는 것보다 빨리 실행되기 때문이다. 또한 테스트와 동일한 프로세스에서 실행되므로, 렌더링된 DOM을 검토하고 확신할 코드를 작성할 수 있다. 실제 브라우저와 마찬가지로, jsdom은 사용자 상호작용을 모델링할 수 있도록 한다. 테스트는 DOM 노드에서 이벤트를 발송한 다음 이러한 동작의 부작용을 관찰하고 주장할 수 있다.(예시) @@ -31,31 +33,26 @@ DOM을 시뮬레이션할 수 없는 환경에서 (예를 들면, Node.js리에 Cypress, puppeteer, webdriver 같은 프레임워크들은 end-to-end 테스트를 진행하기에 유용하다. - ### 모의 함수 {#모의-함수} 테스트를 작성할 때, 우리는 테스트 환경 내부에서 동등성이 없는 우리의 코드 중 일부를 목아웃하고 싶다(예를 들어, navigator.online상태를 Node.js 내부에서 확인하는 것처럼). 테스트는 또한 일부 함수를 감시할 수 있으며 테스트의 다른 부분이 함수들과 어떻게 상호작용하는지를 관찰할 수 있다. 이는 이러한 함수들을 선택적으로 시험 친화적인 버전으로 모의할 수 있다는 점에서 유용하다. 모의함수는 특히 데이터 패칭에 유용하다. 실제 API 종단점으로부터 발생하는 느려짐과 손상을 방지하기 위해 테스트에 "가짜"데이터를 사용하는 것이 바람직하다. 이는 테스트를 예측 가능하게 만들어준다. Jest와 sinon과 같은 라이브러리들은 모의 함수들을 지원한다. 엔드 투 엔드 테스트의 경우, 모의 네트워크가 더 어려울 수 있지만, 그것들의 실제 API 엔드포인트를 테스트하기를 원할 수도 있다. - ### 모의 모듈 {#모의-모듈} 일부 컴포넌트는 테스트 환경에서 잘 작동하지 않거나 테스트에 필수적이지 않은 모듈에 대한 의존성을 가지고 있다. 적절한 교체를 통해 이러한 모듈을 선택적으로 모의하는 것이 유용할 수 있다. Node.js에서 Jest같은 러너는 모의 모듈을 지원한다. 또한 mock-require 라이브러리도 사용할 수 있다. - ### 모의 타이머 {#모의-타이머} 컴포넌트는 setTimeout, setInterval, Data.now와 같은 시간을 기반으로한 함수를 사용할 수 있다. 테스트 환경에서, 이러한 함수들을 수동으로 발전할 수 있는 대체품으로 모의하는 것이 유용할 수 있다. 이것은 테스트가 빨리 진행되도록 하는 데 좋다! 타이머에 의존하는 테스트는 여전히 순서대로 해결되지만 더 빨리 해결된다(예시). Jest, sinon, lolex를 포함한 대부분의 프레임워크는 테스트에서 타이머를 모의할 수 있게 해준다. 가끔, 모의 타이머를 원하지 않는 경우가 있을 수 있다. 예를 들어, 애니메이션을 테스트하거나, 또는 (API 속도 제한 장치와 같은) 타이밍에 민감한 종단점과의 상호작용을 하는 경우가 있다. 타이머 모의가 있는 라이브러리는 테스트/묶음별로 활성화 및 비활성화할 수 있으므로 이러한 테스트 실행 방법을 명시적으로 선택할 수 있다. - ### 엔드 투 엔드 테스트 {#엔드-투-엔드-테스트} - 엔드 투 엔드 테스트는 더 긴 작업흐름을 테스트하는 데 유용하며, 특히 비즈니스에 중요한 작업흐름(결제 또는 등록과 같은)을 테스트하는 데 유용하다. 이러한 경우, 실제 앱 전체를 렌더링하고, 실제 API 종단점에서 데이터를 가져오고, 세션과 쿠키를 사용하며, 다른 링크 사이를 이동하는 방법을 모두 테스트 하기를 원할 것이다. 또한 DOM 상태뿐만 아니라 백업 데이터(예를 들어, 업데이트가 데이터베이스에 유지되었는지 확인하기 위해)에 대해서도 주장하기를 원할 수 있다. 이러한 시나리오에서는 Cypress와 같은 프레임워크나 puppeteer 같은 라이브러리를 사용하여 여러 경로를 탐색하고 브라우저뿐만 아니라 잠재적으로 백엔드에서도 부작용에 대해 주장할 수 있다. From 5c1868f8202e1a71719d5696035c0b9b22e306e7 Mon Sep 17 00:00:00 2001 From: BeomYoung <50603295+BeomYoung@users.noreply.github.com> Date: Tue, 19 Nov 2019 12:32:38 +0900 Subject: [PATCH 11/16] Update testing-environments.md --- content/docs/testing-environments.md | 40 ++++++++++++++-------------- 1 file changed, 20 insertions(+), 20 deletions(-) diff --git a/content/docs/testing-environments.md b/content/docs/testing-environments.md index 51a67cf64..0b2df2ae6 100644 --- a/content/docs/testing-environments.md +++ b/content/docs/testing-environments.md @@ -7,52 +7,52 @@ prev: testing-recipes.html -이 문서는 환경에 영향을 줄 수 있는 요소와 일부 시나리오에 대한 권장 사항을 살펴본다. +이 문서는 환경에 영향을 줄 수 있는 요소와 일부 시나리오에 대한 권장 사항을 살펴봅니다. ### 테스트 {#테스트 러너} -Jest, Mocha, ava와 같은 테스트 러너는 테스트 스위트를 일반 자바 스크립트로 작성하고, 개발 프로세스의 일부로 실행할 수 있도록 한다. 추가적으로, 테스트 스위트는 지속적 통합의 일부로 실행된다. +Jest, Mocha, ava와 같은 테스트 러너는 테스트 스위트를 일반 자바 스크립트로 작성하고, 개발 프로세스의 일부로 실행할 수 있도록 합니다. 추가적으로, 테스트 스위트는 지속적 통합의 일부로 실행됩니다. -Jest는 모의 모듈 및 타이머, 그리고 jsdom 지원 등의 특징을 지원하는 리액트 프로젝트와 광범위하게 호환된다. 만약 리액트 어플을 만들 때, Jest는 이미 유용한 값으로 박스에 포함되어 있다. -mocha같은 라이브러리들은 실제 브라우저 환경에서 작동되며, 이는 분명히 필요한 테스트에 도움이 될 수 있다. -엔드 투 엔드 테스트는 여러 페이지에 걸친 긴 흐름을 테스트하기 위해 사용되며, 다른 설정이 필요하다. +Jest는 모의 모듈 및 타이머, 그리고 jsdom 지원 등의 특징을 지원하는 리액트 프로젝트와 광범위하게 호환됩니다. 만약 리액트 어플을 만들 때, Jest는 이미 유용한 값으로 박스에 포함되어 있습니다. +mocha같은 라이브러리들은 실제 브라우저 환경에서 작동되며, 이는 분명히 필요한 테스트에 도움이 될 수 있습니다. +엔드 투 엔드 테스트는 여러 페이지에 걸친 긴 흐름을 테스트하기 위해 사용되며, 다른 설정이 필요합니다. ### 렌더링 표면에 대한 모의 {#렌더링-표면에-대한-모의} -테스트는 종종 브라우저와 같은 실제 렌더링 표면에 접근하지 않은 환경에서도 진행된다. 이런 환경에서는, Node.js 내에서 실행되는 가벼운 브라우저인 jsdom을 사용하여 브라우저를 시뮬레이션하는 것을 권장한다. +테스트는 종종 브라우저와 같은 실제 렌더링 표면에 접근하지 않은 환경에서도 진행됩니다. 이런 환경에서는, Node.js 내에서 실행되는 가벼운 브라우저인 jsdom을 사용하여 브라우저를 시뮬레이션하는 것을 권장합니다. -대체로, jsdom은 일반 브라우저처럼 동작하지만 레이아웃이나 탐색과 같은 기능은 가지고 있지 않다. 이는 여전히 대부분의 웹 기반 컴포넌트 테스트에 유용하다. 왜냐하면 테스트를 위해 브라우저를 시작하는 것보다 빨리 실행되기 때문이다. 또한 테스트와 동일한 프로세스에서 실행되므로, 렌더링된 DOM을 검토하고 확신할 코드를 작성할 수 있다. +대체로, jsdom은 일반 브라우저처럼 동작하지만 레이아웃이나 탐색과 같은 기능은 가지고 있지 않습니다. 이는 여전히 대부분의 웹 기반 컴포넌트 테스트에 유용합니다. 왜냐하면 테스트를 위해 브라우저를 시작하는 것보다 빨리 실행되기 때문입니다. 또한 테스트와 동일한 프로세스에서 실행되므로, 렌더링된 DOM을 검토하고 확신할 코드를 작성할 수 있습니다. -실제 브라우저와 마찬가지로, jsdom은 사용자 상호작용을 모델링할 수 있도록 한다. 테스트는 DOM 노드에서 이벤트를 발송한 다음 이러한 동작의 부작용을 관찰하고 주장할 수 있다.(예시) +실제 브라우저와 마찬가지로, jsdom은 사용자 상호작용을 모델링할 수 있도록 합니다. 테스트는 DOM 노드에서 이벤트를 발송한 다음 이러한 동작의 부작용을 관찰하고 주장할 수 있습니다.(예시) -UI 테스트의 많은 부분은 위의 설정으로 작성할 수 있다. jsdom에게 렌더링하는 테스트 러너로서, 브라우저 이벤트 시퀀스로 지정된 사용자 상호작용과 함께Jest를 사용하는 것은 act() 도우미에 의해 작동된다.(예시) 예를 들어, 많은 리액트 자체 테스트는 이런 조합으로 작성된다. +UI 테스트의 많은 부분은 위의 설정으로 작성할 수 있습니다. jsdom에게 렌더링하는 테스트 러너로서, 브라우저 이벤트 시퀀스로 지정된 사용자 상호작용과 함께Jest를 사용하는 것은 act() 도우미에 의해 작동됩니다.(예시) 예를 들어, 많은 리액트 자체 테스트는 이런 조합으로 작성됩니다. -만약 대부분의 브라우저별 동작을 테스트하고 레이아웃이나 실제 입력과 같은 네이티브 브라우저 동작을 요구하는 라이브러리를 작성하는 경우 mocha와 같은 프레임 워크를 사용할 수 있다. +만약 대부분의 브라우저별 동작을 테스트하고 레이아웃이나 실제 입력과 같은 네이티브 브라우저 동작을 요구하는 라이브러리를 작성하는 경우 mocha와 같은 프레임 워크를 사용할 수 있습니다. -DOM을 시뮬레이션할 수 없는 환경에서 (예를 들면, Node.js리에서의 리액트 네이티브 컴포넌트 테스트), 엘리먼트와의 상호작용을 시뮬레이션하기 위해 event simulation helpers 를 사용할 수 있다. +DOM을 시뮬레이션할 수 없는 환경에서 (예를 들면, Node.js리에서의 리액트 네이티브 컴포넌트 테스트), 엘리먼트와의 상호작용을 시뮬레이션하기 위해 event simulation helpers 를 사용할 수 있습니다. -Cypress, puppeteer, webdriver 같은 프레임워크들은 end-to-end 테스트를 진행하기에 유용하다. +Cypress, puppeteer, webdriver 같은 프레임워크들은 end-to-end 테스트를 진행하기에 유용합니다. ### 모의 함수 {#모의-함수} -테스트를 작성할 때, 우리는 테스트 환경 내부에서 동등성이 없는 우리의 코드 중 일부를 목아웃하고 싶다(예를 들어, navigator.online상태를 Node.js 내부에서 확인하는 것처럼). 테스트는 또한 일부 함수를 감시할 수 있으며 테스트의 다른 부분이 함수들과 어떻게 상호작용하는지를 관찰할 수 있다. 이는 이러한 함수들을 선택적으로 시험 친화적인 버전으로 모의할 수 있다는 점에서 유용하다. +테스트를 작성할 때, 우리는 테스트 환경 내부에서 동등성이 없는 우리의 코드 중 일부를 목아웃하고 싶어합니다(예를 들어, navigator.online상태를 Node.js 내부에서 확인하는 것처럼). 테스트는 또한 일부 함수를 감시할 수 있으며 테스트의 다른 부분이 함수들과 어떻게 상호작용하는지를 관찰할 수 있습니다. 이는 이러한 함수들을 선택적으로 시험 친화적인 버전으로 모의할 수 있다는 점에서 유용합니다. -모의함수는 특히 데이터 패칭에 유용하다. 실제 API 종단점으로부터 발생하는 느려짐과 손상을 방지하기 위해 테스트에 "가짜"데이터를 사용하는 것이 바람직하다. 이는 테스트를 예측 가능하게 만들어준다. Jest와 sinon과 같은 라이브러리들은 모의 함수들을 지원한다. 엔드 투 엔드 테스트의 경우, 모의 네트워크가 더 어려울 수 있지만, 그것들의 실제 API 엔드포인트를 테스트하기를 원할 수도 있다. +모의함수는 특히 데이터 패칭에 유용합니다. 실제 API 종단점으로부터 발생하는 느려짐과 손상을 방지하기 위해 테스트에 "가짜"데이터를 사용하는 것이 바람직한 방법입니다. 이는 테스트를 예측 가능하게 만들어줍니다. Jest와 sinon과 같은 라이브러리들은 모의 함수들을 지원합니다. 엔드 투 엔드 테스트의 경우, 모의 네트워크가 더 어려울 수 있지만, 그것들의 실제 API 엔드포인트를 테스트하기를 원할 수도 있습니다. ### 모의 모듈 {#모의-모듈} -일부 컴포넌트는 테스트 환경에서 잘 작동하지 않거나 테스트에 필수적이지 않은 모듈에 대한 의존성을 가지고 있다. 적절한 교체를 통해 이러한 모듈을 선택적으로 모의하는 것이 유용할 수 있다. +일부 컴포넌트는 테스트 환경에서 잘 작동하지 않거나 테스트에 필수적이지 않은 모듈에 대한 의존성을 가지고 있습니다. 적절한 교체를 통해 이러한 모듈을 선택적으로 모의하는 것이 유용할 수 있습니다. -Node.js에서 Jest같은 러너는 모의 모듈을 지원한다. 또한 mock-require 라이브러리도 사용할 수 있다. +Node.js에서 Jest같은 러너는 모의 모듈을 지원합니다. 또한 mock-require 라이브러리도 사용할 수 있습니다. ### 모의 타이머 {#모의-타이머} -컴포넌트는 setTimeout, setInterval, Data.now와 같은 시간을 기반으로한 함수를 사용할 수 있다. 테스트 환경에서, 이러한 함수들을 수동으로 발전할 수 있는 대체품으로 모의하는 것이 유용할 수 있다. 이것은 테스트가 빨리 진행되도록 하는 데 좋다! 타이머에 의존하는 테스트는 여전히 순서대로 해결되지만 더 빨리 해결된다(예시). Jest, sinon, lolex를 포함한 대부분의 프레임워크는 테스트에서 타이머를 모의할 수 있게 해준다. +컴포넌트는 setTimeout, setInterval, Data.now와 같은 시간을 기반으로한 함수를 사용할 수 있습니다. 테스트 환경에서, 이러한 함수들을 수동으로 발전할 수 있는 대체품으로 모의하는 것이 유용할 수 있습니다. 이것은 테스트가 빨리 진행되도록 하는 데 좋다! 타이머에 의존하는 테스트는 여전히 순서대로 해결되지만 더 빨리 해결됩니다(예시). Jest, sinon, lolex를 포함한 대부분의 프레임워크는 테스트에서 타이머를 모의할 수 있게 해줍니다. -가끔, 모의 타이머를 원하지 않는 경우가 있을 수 있다. 예를 들어, 애니메이션을 테스트하거나, 또는 (API 속도 제한 장치와 같은) 타이밍에 민감한 종단점과의 상호작용을 하는 경우가 있다. 타이머 모의가 있는 라이브러리는 테스트/묶음별로 활성화 및 비활성화할 수 있으므로 이러한 테스트 실행 방법을 명시적으로 선택할 수 있다. +가끔, 모의 타이머를 원하지 않는 경우가 있을 수 있기도 합니다. 예를 들어, 애니메이션을 테스트하거나, 또는 (API 속도 제한 장치와 같은) 타이밍에 민감한 종단점과의 상호작용을 하는 경우가 있습니다. 타이머 모의가 있는 라이브러리는 테스트/묶음별로 활성화 및 비활성화할 수 있으므로 이러한 테스트 실행 방법을 명시적으로 선택할 수 있습니다. ### 엔드 투 엔드 테스트 {#엔드-투-엔드-테스트} -엔드 투 엔드 테스트는 더 긴 작업흐름을 테스트하는 데 유용하며, 특히 비즈니스에 중요한 작업흐름(결제 또는 등록과 같은)을 테스트하는 데 유용하다. 이러한 경우, 실제 앱 전체를 렌더링하고, 실제 API 종단점에서 데이터를 가져오고, 세션과 쿠키를 사용하며, 다른 링크 사이를 이동하는 방법을 모두 테스트 하기를 원할 것이다. 또한 DOM 상태뿐만 아니라 백업 데이터(예를 들어, 업데이트가 데이터베이스에 유지되었는지 확인하기 위해)에 대해서도 주장하기를 원할 수 있다. +엔드 투 엔드 테스트는 더 긴 작업흐름을 테스트하는 데 유용하며, 특히 비즈니스에 중요한 작업흐름(결제 또는 등록과 같은)을 테스트하는 데 유용합니다. 이러한 경우, 실제 앱 전체를 렌더링하고, 실제 API 종단점에서 데이터를 가져오고, 세션과 쿠키를 사용하며, 다른 링크 사이를 이동하는 방법을 모두 테스트 하기를 원할 것입니다. 또한 DOM 상태뿐만 아니라 백업 데이터(예를 들어, 업데이트가 데이터베이스에 유지되었는지 확인하기 위해)에 대해서도 주장하기를 원할 수 있습니다. -이러한 시나리오에서는 Cypress와 같은 프레임워크나 puppeteer 같은 라이브러리를 사용하여 여러 경로를 탐색하고 브라우저뿐만 아니라 잠재적으로 백엔드에서도 부작용에 대해 주장할 수 있다. +이러한 시나리오에서는 Cypress와 같은 프레임워크나 puppeteer 같은 라이브러리를 사용하여 여러 경로를 탐색하고 브라우저뿐만 아니라 잠재적으로 백엔드에서도 부작용에 대해 주장할 수 있습니다. From d80ad322dbf6e941af3ac11297eb0986e1984f40 Mon Sep 17 00:00:00 2001 From: BeomYoung <50603295+BeomYoung@users.noreply.github.com> Date: Tue, 19 Nov 2019 19:09:00 +0900 Subject: [PATCH 12/16] Update testing-environments.md --- content/docs/testing-environments.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/content/docs/testing-environments.md b/content/docs/testing-environments.md index 0b2df2ae6..7e7d19411 100644 --- a/content/docs/testing-environments.md +++ b/content/docs/testing-environments.md @@ -1,6 +1,6 @@ --- id: testing-environments -title: Testing Environments +title: 테스트 환경 permalink: docs/testing-environments.html prev: testing-recipes.html --- @@ -9,7 +9,7 @@ prev: testing-recipes.html 이 문서는 환경에 영향을 줄 수 있는 요소와 일부 시나리오에 대한 권장 사항을 살펴봅니다. -### 테스트 {#테스트 러너} +### 테스트 {#test-runners} Jest, Mocha, ava와 같은 테스트 러너는 테스트 스위트를 일반 자바 스크립트로 작성하고, 개발 프로세스의 일부로 실행할 수 있도록 합니다. 추가적으로, 테스트 스위트는 지속적 통합의 일부로 실행됩니다. @@ -17,7 +17,7 @@ Jest는 모의 모듈 및 타이머, 그리고 jsdom 지원 등의 특징을 지 mocha같은 라이브러리들은 실제 브라우저 환경에서 작동되며, 이는 분명히 필요한 테스트에 도움이 될 수 있습니다. 엔드 투 엔드 테스트는 여러 페이지에 걸친 긴 흐름을 테스트하기 위해 사용되며, 다른 설정이 필요합니다. -### 렌더링 표면에 대한 모의 {#렌더링-표면에-대한-모의} +### 렌더링 표면에 대한 모의 {#mocking-a-rendering-surface} 테스트는 종종 브라우저와 같은 실제 렌더링 표면에 접근하지 않은 환경에서도 진행됩니다. 이런 환경에서는, Node.js 내에서 실행되는 가벼운 브라우저인 jsdom을 사용하여 브라우저를 시뮬레이션하는 것을 권장합니다. @@ -33,25 +33,25 @@ DOM을 시뮬레이션할 수 없는 환경에서 (예를 들면, Node.js리에 Cypress, puppeteer, webdriver 같은 프레임워크들은 end-to-end 테스트를 진행하기에 유용합니다. -### 모의 함수 {#모의-함수} +### 모의 함수 {#mocking-functions} 테스트를 작성할 때, 우리는 테스트 환경 내부에서 동등성이 없는 우리의 코드 중 일부를 목아웃하고 싶어합니다(예를 들어, navigator.online상태를 Node.js 내부에서 확인하는 것처럼). 테스트는 또한 일부 함수를 감시할 수 있으며 테스트의 다른 부분이 함수들과 어떻게 상호작용하는지를 관찰할 수 있습니다. 이는 이러한 함수들을 선택적으로 시험 친화적인 버전으로 모의할 수 있다는 점에서 유용합니다. 모의함수는 특히 데이터 패칭에 유용합니다. 실제 API 종단점으로부터 발생하는 느려짐과 손상을 방지하기 위해 테스트에 "가짜"데이터를 사용하는 것이 바람직한 방법입니다. 이는 테스트를 예측 가능하게 만들어줍니다. Jest와 sinon과 같은 라이브러리들은 모의 함수들을 지원합니다. 엔드 투 엔드 테스트의 경우, 모의 네트워크가 더 어려울 수 있지만, 그것들의 실제 API 엔드포인트를 테스트하기를 원할 수도 있습니다. -### 모의 모듈 {#모의-모듈} +### 모의 모듈 {#mocking-modules} 일부 컴포넌트는 테스트 환경에서 잘 작동하지 않거나 테스트에 필수적이지 않은 모듈에 대한 의존성을 가지고 있습니다. 적절한 교체를 통해 이러한 모듈을 선택적으로 모의하는 것이 유용할 수 있습니다. Node.js에서 Jest같은 러너는 모의 모듈을 지원합니다. 또한 mock-require 라이브러리도 사용할 수 있습니다. -### 모의 타이머 {#모의-타이머} +### 모의 타이머 {#mocking-timers} 컴포넌트는 setTimeout, setInterval, Data.now와 같은 시간을 기반으로한 함수를 사용할 수 있습니다. 테스트 환경에서, 이러한 함수들을 수동으로 발전할 수 있는 대체품으로 모의하는 것이 유용할 수 있습니다. 이것은 테스트가 빨리 진행되도록 하는 데 좋다! 타이머에 의존하는 테스트는 여전히 순서대로 해결되지만 더 빨리 해결됩니다(예시). Jest, sinon, lolex를 포함한 대부분의 프레임워크는 테스트에서 타이머를 모의할 수 있게 해줍니다. 가끔, 모의 타이머를 원하지 않는 경우가 있을 수 있기도 합니다. 예를 들어, 애니메이션을 테스트하거나, 또는 (API 속도 제한 장치와 같은) 타이밍에 민감한 종단점과의 상호작용을 하는 경우가 있습니다. 타이머 모의가 있는 라이브러리는 테스트/묶음별로 활성화 및 비활성화할 수 있으므로 이러한 테스트 실행 방법을 명시적으로 선택할 수 있습니다. -### 엔드 투 엔드 테스트 {#엔드-투-엔드-테스트} +### 엔드 투 엔드 테스트 {#end-to-end-tests-aka-e2e-tests} 엔드 투 엔드 테스트는 더 긴 작업흐름을 테스트하는 데 유용하며, 특히 비즈니스에 중요한 작업흐름(결제 또는 등록과 같은)을 테스트하는 데 유용합니다. 이러한 경우, 실제 앱 전체를 렌더링하고, 실제 API 종단점에서 데이터를 가져오고, 세션과 쿠키를 사용하며, 다른 링크 사이를 이동하는 방법을 모두 테스트 하기를 원할 것입니다. 또한 DOM 상태뿐만 아니라 백업 데이터(예를 들어, 업데이트가 데이터베이스에 유지되었는지 확인하기 위해)에 대해서도 주장하기를 원할 수 있습니다. From 089d6b779d8e0dd1297128ea0772be56d8e8a16a Mon Sep 17 00:00:00 2001 From: BeomYoung <50603295+BeomYoung@users.noreply.github.com> Date: Tue, 19 Nov 2019 20:15:29 +0900 Subject: [PATCH 13/16] Update testing-environments.md --- content/docs/testing-environments.md | 32 ++++++++++++++-------------- 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/content/docs/testing-environments.md b/content/docs/testing-environments.md index 7e7d19411..6e9c8308f 100644 --- a/content/docs/testing-environments.md +++ b/content/docs/testing-environments.md @@ -11,43 +11,43 @@ prev: testing-recipes.html ### 테스트 {#test-runners} -Jest, Mocha, ava와 같은 테스트 러너는 테스트 스위트를 일반 자바 스크립트로 작성하고, 개발 프로세스의 일부로 실행할 수 있도록 합니다. 추가적으로, 테스트 스위트는 지속적 통합의 일부로 실행됩니다. +[Jest](https://jestjs.io/), [Mocha](https://mochajs.org/), [ava](https://github.com/avajs/ava)와 같은 테스트 러너는 테스트 스위트를 일반 자바 스크립트로 작성하고, 개발 프로세스의 일부로 실행할 수 있도록 합니다. 추가적으로, 테스트 스위트는 지속적 통합의 일부로 실행됩니다. -Jest는 모의 모듈 및 타이머, 그리고 jsdom 지원 등의 특징을 지원하는 리액트 프로젝트와 광범위하게 호환됩니다. 만약 리액트 어플을 만들 때, Jest는 이미 유용한 값으로 박스에 포함되어 있습니다. -mocha같은 라이브러리들은 실제 브라우저 환경에서 작동되며, 이는 분명히 필요한 테스트에 도움이 될 수 있습니다. -엔드 투 엔드 테스트는 여러 페이지에 걸친 긴 흐름을 테스트하기 위해 사용되며, 다른 설정이 필요합니다. +Jest는 모의 [모듈](https://github.com/reactjs/ko.reactjs.org/blob/master/content/docs/testing-environments.md#mocking-modules) 및 [타이머](https://github.com/reactjs/ko.reactjs.org/blob/master/content/docs/testing-environments.md#mocking-timers), 그리고 [jsdom](https://github.com/reactjs/ko.reactjs.org/blob/master/content/docs/testing-environments.md#mocking-a-rendering-surface) 지원 등의 특징을 지원하는 리액트 프로젝트와 광범위하게 호환됩니다. **만약 리액트 어플을 만들 때**, Jest는 이미 **유용한 값**으로 [박스에 포함되어 있습니다.](https://create-react-app.dev/docs/running-tests/) +[mocha](https://mochajs.org/#running-mocha-in-the-browser)같은 라이브러리들은 실제 브라우저 환경에서 작동되며, 이는 분명히 필요한 테스트에 도움이 될 수 있습니다. +엔드 투 엔드 테스트는 여러 페이지에 걸친 긴 흐름을 테스트하기 위해 사용되며, [다른 설정](https://github.com/reactjs/ko.reactjs.org/blob/master/content/docs/testing-environments.md#end-to-end-tests-aka-e2e-tests)이 필요합니다. ### 렌더링 표면에 대한 모의 {#mocking-a-rendering-surface} -테스트는 종종 브라우저와 같은 실제 렌더링 표면에 접근하지 않은 환경에서도 진행됩니다. 이런 환경에서는, Node.js 내에서 실행되는 가벼운 브라우저인 jsdom을 사용하여 브라우저를 시뮬레이션하는 것을 권장합니다. +테스트는 종종 브라우저와 같은 실제 렌더링 표면에 접근하지 않은 환경에서도 진행됩니다. 이런 환경에서는, Node.js 내에서 실행되는 가벼운 브라우저인 [jsdom](https://github.com/jsdom/jsdom)을 사용하여 브라우저를 시뮬레이션하는 것을 권장합니다. -대체로, jsdom은 일반 브라우저처럼 동작하지만 레이아웃이나 탐색과 같은 기능은 가지고 있지 않습니다. 이는 여전히 대부분의 웹 기반 컴포넌트 테스트에 유용합니다. 왜냐하면 테스트를 위해 브라우저를 시작하는 것보다 빨리 실행되기 때문입니다. 또한 테스트와 동일한 프로세스에서 실행되므로, 렌더링된 DOM을 검토하고 확신할 코드를 작성할 수 있습니다. +대체로, jsdom은 일반 브라우저처럼 동작하지만 [레이아웃이나 탐색](https://github.com/jsdom/jsdom#unimplemented-parts-of-the-web-platform)과 같은 기능은 가지고 있지 않습니다. 이는 여전히 대부분의 웹 기반 컴포넌트 테스트에 유용합니다. 왜냐하면 테스트를 위해 브라우저를 시작하는 것보다 빨리 실행되기 때문입니다. 또한 테스트와 동일한 프로세스에서 실행되므로, 렌더링된 DOM을 검토하고 확신할 코드를 작성할 수 있습니다. -실제 브라우저와 마찬가지로, jsdom은 사용자 상호작용을 모델링할 수 있도록 합니다. 테스트는 DOM 노드에서 이벤트를 발송한 다음 이러한 동작의 부작용을 관찰하고 주장할 수 있습니다.(예시) +실제 브라우저와 마찬가지로, jsdom은 사용자 상호작용을 모델링할 수 있도록 합니다. 테스트는 DOM 노드에서 이벤트를 발송한 다음 이러한 동작의 부작용을 관찰하고 주장할 수 있습니다.[(예시)](https://github.com/reactjs/ko.reactjs.org/blob/master/docs/testing-recipes.html#events) -UI 테스트의 많은 부분은 위의 설정으로 작성할 수 있습니다. jsdom에게 렌더링하는 테스트 러너로서, 브라우저 이벤트 시퀀스로 지정된 사용자 상호작용과 함께Jest를 사용하는 것은 act() 도우미에 의해 작동됩니다.(예시) 예를 들어, 많은 리액트 자체 테스트는 이런 조합으로 작성됩니다. +UI 테스트의 많은 부분은 위의 설정으로 작성할 수 있습니다. jsdom에게 렌더링하는 테스트 러너로서, 브라우저 이벤트 시퀀스로 지정된 사용자 상호작용과 함께Jest를 사용하는 것은 act() 도우미에 의해 작동됩니다.[(예시)](https://github.com/reactjs/ko.reactjs.org/blob/master/docs/testing-recipes.html) 예를 들어, 많은 리액트 자체 테스트는 이런 조합으로 작성됩니다. -만약 대부분의 브라우저별 동작을 테스트하고 레이아웃이나 실제 입력과 같은 네이티브 브라우저 동작을 요구하는 라이브러리를 작성하는 경우 mocha와 같은 프레임 워크를 사용할 수 있습니다. +만약 대부분의 브라우저별 동작을 테스트하고 레이아웃이나 실제 입력과 같은 네이티브 브라우저 동작을 요구하는 라이브러리를 작성하는 경우 [mocha](https://mochajs.org/)와 같은 프레임 워크를 사용할 수 있습니다. -DOM을 시뮬레이션할 수 없는 환경에서 (예를 들면, Node.js리에서의 리액트 네이티브 컴포넌트 테스트), 엘리먼트와의 상호작용을 시뮬레이션하기 위해 event simulation helpers 를 사용할 수 있습니다. +DOM을 시뮬레이션할 수 없는 환경에서 (예를 들면, Node.js리에서의 리액트 네이티브 컴포넌트 테스트), 엘리먼트와의 상호작용을 시뮬레이션하기 위해 [event simulation helpers](https://reactjs.org/docs/test-utils.html#simulate) 를 사용할 수 있습니다. -Cypress, puppeteer, webdriver 같은 프레임워크들은 end-to-end 테스트를 진행하기에 유용합니다. +[Cypress](https://www.cypress.io/), [puppeteer](https://github.com/GoogleChrome/puppeteer), [webdriver](https://selenium.dev/projects/) 같은 프레임워크들은 [end-to-end](https://github.com/reactjs/ko.reactjs.org/blob/master/content/docs/testing-environments.md#end-to-end-tests-aka-e2e-tests) 테스트를 진행하기에 유용합니다. ### 모의 함수 {#mocking-functions} 테스트를 작성할 때, 우리는 테스트 환경 내부에서 동등성이 없는 우리의 코드 중 일부를 목아웃하고 싶어합니다(예를 들어, navigator.online상태를 Node.js 내부에서 확인하는 것처럼). 테스트는 또한 일부 함수를 감시할 수 있으며 테스트의 다른 부분이 함수들과 어떻게 상호작용하는지를 관찰할 수 있습니다. 이는 이러한 함수들을 선택적으로 시험 친화적인 버전으로 모의할 수 있다는 점에서 유용합니다. -모의함수는 특히 데이터 패칭에 유용합니다. 실제 API 종단점으로부터 발생하는 느려짐과 손상을 방지하기 위해 테스트에 "가짜"데이터를 사용하는 것이 바람직한 방법입니다. 이는 테스트를 예측 가능하게 만들어줍니다. Jest와 sinon과 같은 라이브러리들은 모의 함수들을 지원합니다. 엔드 투 엔드 테스트의 경우, 모의 네트워크가 더 어려울 수 있지만, 그것들의 실제 API 엔드포인트를 테스트하기를 원할 수도 있습니다. +모의함수는 특히 데이터 패칭에 유용합니다. 실제 API 종단점으로부터 발생하는 느려짐과 손상을 방지하기 위해 테스트에 "가짜"데이터를 사용하는 것이 바람직한 방법입니다[(예시)](https://github.com/reactjs/ko.reactjs.org/blob/master/docs/testing-recipes.html#data-fetching). 이는 테스트를 예측 가능하게 만들어줍니다. [Jest](https://jestjs.io/)와 [sinon](https://sinonjs.org/)과 같은 라이브러리들은 모의 함수들을 지원합니다. 엔드 투 엔드 테스트의 경우, 모의 네트워크가 더 어려울 수 있지만, 그것들의 실제 API 엔드포인트를 테스트하기를 원할 수도 있습니다. ### 모의 모듈 {#mocking-modules} -일부 컴포넌트는 테스트 환경에서 잘 작동하지 않거나 테스트에 필수적이지 않은 모듈에 대한 의존성을 가지고 있습니다. 적절한 교체를 통해 이러한 모듈을 선택적으로 모의하는 것이 유용할 수 있습니다. +일부 컴포넌트는 테스트 환경에서 잘 작동하지 않거나 테스트에 필수적이지 않은 모듈에 대한 의존성을 가지고 있습니다. 적절한 교체를 통해 이러한 모듈을 선택적으로 모의하는 것이 유용할 수 있습니다[(예시)](https://github.com/reactjs/ko.reactjs.org/blob/master/docs/testing-recipes.html#mocking-modules). -Node.js에서 Jest같은 러너는 모의 모듈을 지원합니다. 또한 mock-require 라이브러리도 사용할 수 있습니다. +Node.js에서 Jest같은 러너는 [모의 모듈을 지원합니다](https://jestjs.io/docs/en/manual-mocks). 또한 [mock-require](https://www.npmjs.com/package/mock-require) 라이브러리도 사용할 수 있습니다. ### 모의 타이머 {#mocking-timers} -컴포넌트는 setTimeout, setInterval, Data.now와 같은 시간을 기반으로한 함수를 사용할 수 있습니다. 테스트 환경에서, 이러한 함수들을 수동으로 발전할 수 있는 대체품으로 모의하는 것이 유용할 수 있습니다. 이것은 테스트가 빨리 진행되도록 하는 데 좋다! 타이머에 의존하는 테스트는 여전히 순서대로 해결되지만 더 빨리 해결됩니다(예시). Jest, sinon, lolex를 포함한 대부분의 프레임워크는 테스트에서 타이머를 모의할 수 있게 해줍니다. +컴포넌트는 setTimeout, setInterval, Data.now와 같은 시간을 기반으로한 함수를 사용할 수 있습니다. 테스트 환경에서, 이러한 함수들을 수동으로 발전할 수 있는 대체품으로 모의하는 것이 유용할 수 있습니다. 이것은 테스트가 빨리 진행되도록 하는 데 좋다! 타이머에 의존하는 테스트는 여전히 순서대로 해결되지만 더 빨리 해결됩니다[(예시)](https://github.com/reactjs/ko.reactjs.org/blob/master/docs/testing-recipes.html#timers). [Jest](https://jestjs.io/docs/en/timer-mocks), [sinon](https://sinonjs.org/releases/v7.3.2/fake-timers/), [lolex](https://github.com/sinonjs/lolex)를 포함한 대부분의 프레임워크는 테스트에서 타이머를 모의할 수 있게 해줍니다. 가끔, 모의 타이머를 원하지 않는 경우가 있을 수 있기도 합니다. 예를 들어, 애니메이션을 테스트하거나, 또는 (API 속도 제한 장치와 같은) 타이밍에 민감한 종단점과의 상호작용을 하는 경우가 있습니다. 타이머 모의가 있는 라이브러리는 테스트/묶음별로 활성화 및 비활성화할 수 있으므로 이러한 테스트 실행 방법을 명시적으로 선택할 수 있습니다. @@ -55,4 +55,4 @@ Node.js에서 Jest같은 러너는 모의 모듈을 지원합니다. 또한 mock 엔드 투 엔드 테스트는 더 긴 작업흐름을 테스트하는 데 유용하며, 특히 비즈니스에 중요한 작업흐름(결제 또는 등록과 같은)을 테스트하는 데 유용합니다. 이러한 경우, 실제 앱 전체를 렌더링하고, 실제 API 종단점에서 데이터를 가져오고, 세션과 쿠키를 사용하며, 다른 링크 사이를 이동하는 방법을 모두 테스트 하기를 원할 것입니다. 또한 DOM 상태뿐만 아니라 백업 데이터(예를 들어, 업데이트가 데이터베이스에 유지되었는지 확인하기 위해)에 대해서도 주장하기를 원할 수 있습니다. -이러한 시나리오에서는 Cypress와 같은 프레임워크나 puppeteer 같은 라이브러리를 사용하여 여러 경로를 탐색하고 브라우저뿐만 아니라 잠재적으로 백엔드에서도 부작용에 대해 주장할 수 있습니다. +이러한 시나리오에서는 [Cypress](https://www.cypress.io/)와 같은 프레임워크나 [puppeteer](https://github.com/GoogleChrome/puppeteer) 같은 라이브러리를 사용하여 여러 경로를 탐색하고 브라우저뿐만 아니라 잠재적으로 백엔드에서도 부작용에 대해 주장할 수 있습니다. From 95c364ad4dd975a3e63754da2b62e365d5aaebaf Mon Sep 17 00:00:00 2001 From: Taehwan Noh Date: Sun, 10 May 2020 14:20:55 +0900 Subject: [PATCH 14/16] Apply suggestions from code review --- content/docs/testing-environments.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/content/docs/testing-environments.md b/content/docs/testing-environments.md index 7c962dc72..2c2d6ccf6 100644 --- a/content/docs/testing-environments.md +++ b/content/docs/testing-environments.md @@ -13,17 +13,17 @@ prev: testing-recipes.html [Jest](https://jestjs.io/), [Mocha](https://mochajs.org/), [ava](https://github.com/avajs/ava)와 같은 테스트 러너는 테스트 스위트를 일반 자바 스크립트로 작성하고, 개발 프로세스의 일부로 실행할 수 있도록 합니다. 추가적으로, 테스트 스위트는 지속적 통합의 일부로 실행됩니다. -Jest는 모의 [모듈](https://github.com/reactjs/ko.reactjs.org/blob/master/content/docs/testing-environments.md#mocking-modules) 및 [타이머](https://github.com/reactjs/ko.reactjs.org/blob/master/content/docs/testing-environments.md#mocking-timers), 그리고 [jsdom](https://github.com/reactjs/ko.reactjs.org/blob/master/content/docs/testing-environments.md#mocking-a-rendering-surface) 지원 등의 특징을 지원하는 리액트 프로젝트와 광범위하게 호환됩니다. **만약 리액트 어플을 만들 때**, Jest는 이미 **유용한 값**으로 [박스에 포함되어 있습니다.](https://create-react-app.dev/docs/running-tests/) -[mocha](https://mochajs.org/#running-mocha-in-the-browser)같은 라이브러리들은 실제 브라우저 환경에서 작동되며, 이는 분명히 필요한 테스트에 도움이 될 수 있습니다. -엔드 투 엔드 테스트는 여러 페이지에 걸친 긴 흐름을 테스트하기 위해 사용되며, [다른 설정](https://github.com/reactjs/ko.reactjs.org/blob/master/content/docs/testing-environments.md#end-to-end-tests-aka-e2e-tests)이 필요합니다. +Jest는 모의 [모듈](#mocking-modules) 및 [타이머](#mocking-timers), 그리고 [jsdom](#mocking-a-rendering-surface) 지원 등 여러 기능을 지원하는 React 프로젝트와 광범위하게 호환됩니다. **React 앱을 만들 때, Jest는 이미 유용한 도구로 [상자에 포함되어 있습니다.](https://create-react-app.dev/docs/running-tests/)** +[mocha](https://mochajs.org/#running-mocha-in-the-browser)같은 라이브러리들은 실제 브라우저 환경에서도 잘 작동하며, 이는 분명히 필요한 테스트에 도움이 될 수 있습니다. +엔드 투 엔드 테스트는 여러 페이지에 걸친 긴 흐름을 테스트하기 위해 사용되며, [다른 설정](#end-to-end-tests-aka-e2e-tests)이 필요합니다. ### 렌더링 표면에 대한 모의 {#mocking-a-rendering-surface} 테스트는 종종 브라우저와 같은 실제 렌더링 표면에 접근하지 않은 환경에서도 진행됩니다. 이런 환경에서는, Node.js 내에서 실행되는 가벼운 브라우저인 [jsdom](https://github.com/jsdom/jsdom)을 사용하여 브라우저를 시뮬레이션하는 것을 권장합니다. -대체로, jsdom은 일반 브라우저처럼 동작하지만 [레이아웃이나 탐색](https://github.com/jsdom/jsdom#unimplemented-parts-of-the-web-platform)과 같은 기능은 가지고 있지 않습니다. 이는 여전히 대부분의 웹 기반 컴포넌트 테스트에 유용합니다. 왜냐하면 테스트를 위해 브라우저를 시작하는 것보다 빨리 실행되기 때문입니다. 또한 테스트와 동일한 프로세스에서 실행되므로, 렌더링된 DOM을 검토하고 확신할 코드를 작성할 수 있습니다. +대체로, jsdom은 일반 브라우저처럼 동작하지만 [레이아웃이나 탐색](https://github.com/jsdom/jsdom#unimplemented-parts-of-the-web-platform)과 같은 기능은 가지고 있지 않습니다. 이는 여전히 대부분의 웹 기반 컴포넌트 테스트에 유용합니다. 왜냐하면 테스트를 위해 브라우저를 시작하는 것보다 빨리 실행되기 때문입니다. 또한 테스트와 동일한 프로세스에서 실행되므로, 렌더링된 DOM을 검토하고 검증할 코드를 작성할 수 있습니다. -실제 브라우저와 마찬가지로, jsdom은 사용자 상호작용을 모델링할 수 있도록 합니다. 테스트는 DOM 노드에서 이벤트를 발송한 다음 이러한 동작의 부작용을 관찰하고 주장할 수 있습니다.[(예시)](https://github.com/reactjs/ko.reactjs.org/blob/master/docs/testing-recipes.html#events) +실제 브라우저와 마찬가지로, jsdom은 사용자 상호작용을 모델링할 수 있도록 합니다. 테스트는 DOM 노드에서 이벤트를 발송한 다음 이러한 동작의 부작용을 관찰하고 검증할 수 있습니다. [(예시)](/docs/testing-recipes.html#events) UI 테스트의 많은 부분은 위의 설정으로 작성할 수 있습니다. jsdom에게 렌더링하는 테스트 러너로서, 브라우저 이벤트 시퀀스로 지정된 사용자 상호작용과 함께Jest를 사용하는 것은 act() 도우미에 의해 작동됩니다.[(예시)](https://github.com/reactjs/ko.reactjs.org/blob/master/docs/testing-recipes.html) 예를 들어, 많은 리액트 자체 테스트는 이런 조합으로 작성됩니다. @@ -31,17 +31,17 @@ UI 테스트의 많은 부분은 위의 설정으로 작성할 수 있습니다. DOM을 시뮬레이션*할 수 없는* 환경에서 (예를 들면, Node.js에서 React Native 컴포넌트 테스트), 엘리먼트와의 상호작용을 시뮬레이션하기 위해 [event simulation helpers](https://reactjs.org/docs/test-utils.html#simulate)를 사용할 수 있습니다. 다른 대안으로, [`@testing-library/react-native`](https://testing-library.com/docs/native-testing-library)의 `fireEvent` 헬퍼를 사용할 수 있습니다. -[Cypress](https://www.cypress.io/), [puppeteer](https://github.com/GoogleChrome/puppeteer), [webdriver](https://selenium.dev/projects/) 같은 프레임워크들은 [end-to-end](https://github.com/reactjs/ko.reactjs.org/blob/master/content/docs/testing-environments.md#end-to-end-tests-aka-e2e-tests) 테스트를 진행하기에 유용합니다. +[Cypress](https://www.cypress.io/), [puppeteer](https://github.com/GoogleChrome/puppeteer), [webdriver](https://www.seleniumhq.org/projects/webdriver/) 같은 프레임워크들은 [end-to-end 테스트](#end-to-end-tests-aka-e2e-tests)를 진행하기에 유용합니다. ### 모의 함수 {#mocking-functions} 테스트를 작성할 때, 우리는 테스트 환경 내부에서 동등성이 없는 우리의 코드 중 일부를 목아웃하고 싶어합니다(예를 들어, navigator.online상태를 Node.js 내부에서 확인하는 것처럼). 테스트는 또한 일부 함수를 감시할 수 있으며 테스트의 다른 부분이 함수들과 어떻게 상호작용하는지를 관찰할 수 있습니다. 이는 이러한 함수들을 선택적으로 시험 친화적인 버전으로 모의할 수 있다는 점에서 유용합니다. -모의함수는 특히 데이터 패칭에 유용합니다. 실제 API 종단점으로부터 발생하는 느려짐과 손상을 방지하기 위해 테스트에 "가짜"데이터를 사용하는 것이 바람직한 방법입니다[(예시)](https://github.com/reactjs/ko.reactjs.org/blob/master/docs/testing-recipes.html#data-fetching). 이는 테스트를 예측 가능하게 만들어줍니다. [Jest](https://jestjs.io/)와 [sinon](https://sinonjs.org/)과 같은 라이브러리들은 모의 함수들을 지원합니다. 엔드 투 엔드 테스트의 경우, 모의 네트워크가 더 어려울 수 있지만, 그것들의 실제 API 엔드포인트를 테스트하기를 원할 수도 있습니다. +모의 함수는 특히 데이터를 불러올 때 유용합니다. 실제 API 종단점으로부터 발생하는 느려짐과 손상을 방지하기 위해 테스트에 "가짜"데이터를 사용하는 것이 바람직한 방법입니다 [(예시)](/docs/testing-recipes.html#data-fetching). 이는 테스트를 예측 가능하게 만들어줍니다. [Jest](https://jestjs.io/)와 [sinon](https://sinonjs.org/)과 같은 라이브러리들은 모의 함수들을 지원합니다. 엔드 투 엔드 테스트의 경우 네트워크를 모사하는 것은 어려울 수 있지만, 실제 API 엔드포인트를 테스트하기를 원할 수도 있습니다. ### 모의 모듈 {#mocking-modules} -일부 컴포넌트는 테스트 환경에서 잘 작동하지 않거나 테스트에 필수적이지 않은 모듈에 대한 의존성을 가지고 있습니다. 적절한 교체를 통해 이러한 모듈을 선택적으로 모의하는 것이 유용할 수 있습니다[(예시)](https://github.com/reactjs/ko.reactjs.org/blob/master/docs/testing-recipes.html#mocking-modules). +일부 컴포넌트는 테스트 환경에서 잘 작동하지 않거나 테스트에 필수적이지 않은 모듈에 대한 의존성을 가지고 있습니다. 적절한 교체를 통해 이러한 모듈을 선택적으로 모의하는 것이 유용할 수 있습니다 [(예시)](/docs/testing-recipes.html#mocking-modules). Node.js에서 Jest같은 러너는 [모의 모듈을 지원합니다](https://jestjs.io/docs/en/manual-mocks). 또한 [mock-require](https://www.npmjs.com/package/mock-require) 라이브러리도 사용할 수 있습니다. From a56bca951549bc5ec5bde155b0fc08c68d59c21d Mon Sep 17 00:00:00 2001 From: Taehwan Noh Date: Sun, 10 May 2020 14:25:01 +0900 Subject: [PATCH 15/16] Updtae link and some sentence --- content/docs/testing-environments.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/docs/testing-environments.md b/content/docs/testing-environments.md index 2c2d6ccf6..5d8c34d5a 100644 --- a/content/docs/testing-environments.md +++ b/content/docs/testing-environments.md @@ -25,17 +25,17 @@ Jest는 모의 [모듈](#mocking-modules) 및 [타이머](#mocking-timers), 그 실제 브라우저와 마찬가지로, jsdom은 사용자 상호작용을 모델링할 수 있도록 합니다. 테스트는 DOM 노드에서 이벤트를 발송한 다음 이러한 동작의 부작용을 관찰하고 검증할 수 있습니다. [(예시)](/docs/testing-recipes.html#events) -UI 테스트의 많은 부분은 위의 설정으로 작성할 수 있습니다. jsdom에게 렌더링하는 테스트 러너로서, 브라우저 이벤트 시퀀스로 지정된 사용자 상호작용과 함께Jest를 사용하는 것은 act() 도우미에 의해 작동됩니다.[(예시)](https://github.com/reactjs/ko.reactjs.org/blob/master/docs/testing-recipes.html) 예를 들어, 많은 리액트 자체 테스트는 이런 조합으로 작성됩니다. +UI 테스트의 많은 부분은 위의 설정으로 작성할 수 있습니다. jsdom에게 렌더링하는 테스트 러너로서, 브라우저 이벤트 시퀀스로 지정된 사용자 상호작용과 함께Jest를 사용하는 것은 act() 도우미에 의해 작동됩니다.[(예시)](/docs/testing-recipes.html) 예를 들어, 많은 React 자체 테스트는 이런 조합으로 작성됩니다. 만약 대부분의 브라우저별 동작을 테스트하고 레이아웃이나 실제 입력과 같은 네이티브 브라우저 동작을 요구하는 라이브러리를 작성하는 경우 [mocha](https://mochajs.org/)와 같은 프레임 워크를 사용할 수 있습니다. -DOM을 시뮬레이션*할 수 없는* 환경에서 (예를 들면, Node.js에서 React Native 컴포넌트 테스트), 엘리먼트와의 상호작용을 시뮬레이션하기 위해 [event simulation helpers](https://reactjs.org/docs/test-utils.html#simulate)를 사용할 수 있습니다. 다른 대안으로, [`@testing-library/react-native`](https://testing-library.com/docs/native-testing-library)의 `fireEvent` 헬퍼를 사용할 수 있습니다. +DOM을 시뮬레이션*할 수 없는* 환경에서 (예를 들면, Node.js에서 React Native 컴포넌트 테스트), 엘리먼트와의 상호작용을 시뮬레이션하기 위해 [event simulation helpers](/docs/test-utils.html#simulate)를 사용할 수 있습니다. 다른 대안으로, [`@testing-library/react-native`](https://testing-library.com/docs/native-testing-library)의 `fireEvent` 헬퍼를 사용할 수 있습니다. [Cypress](https://www.cypress.io/), [puppeteer](https://github.com/GoogleChrome/puppeteer), [webdriver](https://www.seleniumhq.org/projects/webdriver/) 같은 프레임워크들은 [end-to-end 테스트](#end-to-end-tests-aka-e2e-tests)를 진행하기에 유용합니다. ### 모의 함수 {#mocking-functions} -테스트를 작성할 때, 우리는 테스트 환경 내부에서 동등성이 없는 우리의 코드 중 일부를 목아웃하고 싶어합니다(예를 들어, navigator.online상태를 Node.js 내부에서 확인하는 것처럼). 테스트는 또한 일부 함수를 감시할 수 있으며 테스트의 다른 부분이 함수들과 어떻게 상호작용하는지를 관찰할 수 있습니다. 이는 이러한 함수들을 선택적으로 시험 친화적인 버전으로 모의할 수 있다는 점에서 유용합니다. +테스트를 작성할 때, 우리는 테스트 환경 내부에서 동등성이 없는 우리의 코드 중 일부를 목아웃하고 싶어합니다(예를 들어, `navigator.onLine` 상태를 Node.js 내부에서 확인하는 것처럼). 테스트는 또한 일부 함수를 감시할 수 있으며 테스트의 다른 부분이 함수들과 어떻게 상호작용하는지를 관찰할 수 있습니다. 이는 이러한 함수들을 선택적으로 시험 친화적인 버전으로 모의할 수 있다는 점에서 유용합니다. 모의 함수는 특히 데이터를 불러올 때 유용합니다. 실제 API 종단점으로부터 발생하는 느려짐과 손상을 방지하기 위해 테스트에 "가짜"데이터를 사용하는 것이 바람직한 방법입니다 [(예시)](/docs/testing-recipes.html#data-fetching). 이는 테스트를 예측 가능하게 만들어줍니다. [Jest](https://jestjs.io/)와 [sinon](https://sinonjs.org/)과 같은 라이브러리들은 모의 함수들을 지원합니다. 엔드 투 엔드 테스트의 경우 네트워크를 모사하는 것은 어려울 수 있지만, 실제 API 엔드포인트를 테스트하기를 원할 수도 있습니다. From c3891dab3ff908352ebd7f5f42473e01a5cbc19a Mon Sep 17 00:00:00 2001 From: Taehwan Noh Date: Sun, 10 May 2020 14:43:41 +0900 Subject: [PATCH 16/16] Update section title and some sentence --- content/docs/testing-environments.md | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/content/docs/testing-environments.md b/content/docs/testing-environments.md index 5d8c34d5a..421af5c8b 100644 --- a/content/docs/testing-environments.md +++ b/content/docs/testing-environments.md @@ -9,45 +9,45 @@ prev: testing-recipes.html 이 문서는 환경에 영향을 줄 수 있는 요소와 일부 시나리오에 대한 권장 사항을 살펴봅니다. -### 테스트 {#test-runners} +### 테스트 러너 {#test-runners} [Jest](https://jestjs.io/), [Mocha](https://mochajs.org/), [ava](https://github.com/avajs/ava)와 같은 테스트 러너는 테스트 스위트를 일반 자바 스크립트로 작성하고, 개발 프로세스의 일부로 실행할 수 있도록 합니다. 추가적으로, 테스트 스위트는 지속적 통합의 일부로 실행됩니다. -Jest는 모의 [모듈](#mocking-modules) 및 [타이머](#mocking-timers), 그리고 [jsdom](#mocking-a-rendering-surface) 지원 등 여러 기능을 지원하는 React 프로젝트와 광범위하게 호환됩니다. **React 앱을 만들 때, Jest는 이미 유용한 도구로 [상자에 포함되어 있습니다.](https://create-react-app.dev/docs/running-tests/)** -[mocha](https://mochajs.org/#running-mocha-in-the-browser)같은 라이브러리들은 실제 브라우저 환경에서도 잘 작동하며, 이는 분명히 필요한 테스트에 도움이 될 수 있습니다. -엔드 투 엔드 테스트는 여러 페이지에 걸친 긴 흐름을 테스트하기 위해 사용되며, [다른 설정](#end-to-end-tests-aka-e2e-tests)이 필요합니다. +- Jest는 모의 [모듈](#mocking-modules) 및 [타이머](#mocking-timers), 그리고 [jsdom](#mocking-a-rendering-surface) 지원 등 여러 기능을 지원하는 React 프로젝트와 광범위하게 호환됩니다. **Create React App을 사용한다면, [Jest는 이미 유용한 기본값과 함께 포함되어 있습니다.](https://create-react-app.dev/docs/running-tests/)** +- [mocha](https://mochajs.org/#running-mocha-in-the-browser)같은 라이브러리는 실제 브라우저 환경에서도 잘 작동하며, 이는 분명히 필요한 테스트에 도움이 될 수 있습니다. +- 엔드 투 엔드 테스트는 여러 페이지에 걸친 긴 흐름을 테스트하기 위해 사용되며, [다른 설정](#end-to-end-tests-aka-e2e-tests)이 필요합니다. -### 렌더링 표면에 대한 모의 {#mocking-a-rendering-surface} +### 렌더링 표면에 대한 모의하기 {#mocking-a-rendering-surface} 테스트는 종종 브라우저와 같은 실제 렌더링 표면에 접근하지 않은 환경에서도 진행됩니다. 이런 환경에서는, Node.js 내에서 실행되는 가벼운 브라우저인 [jsdom](https://github.com/jsdom/jsdom)을 사용하여 브라우저를 시뮬레이션하는 것을 권장합니다. 대체로, jsdom은 일반 브라우저처럼 동작하지만 [레이아웃이나 탐색](https://github.com/jsdom/jsdom#unimplemented-parts-of-the-web-platform)과 같은 기능은 가지고 있지 않습니다. 이는 여전히 대부분의 웹 기반 컴포넌트 테스트에 유용합니다. 왜냐하면 테스트를 위해 브라우저를 시작하는 것보다 빨리 실행되기 때문입니다. 또한 테스트와 동일한 프로세스에서 실행되므로, 렌더링된 DOM을 검토하고 검증할 코드를 작성할 수 있습니다. -실제 브라우저와 마찬가지로, jsdom은 사용자 상호작용을 모델링할 수 있도록 합니다. 테스트는 DOM 노드에서 이벤트를 발송한 다음 이러한 동작의 부작용을 관찰하고 검증할 수 있습니다. [(예시)](/docs/testing-recipes.html#events) +실제 브라우저와 마찬가지로, jsdom은 사용자 상호작용을 모델링할 수 있도록 합니다. 테스트는 DOM 노드에서 이벤트를 발송한 다음 이러한 동작의 부작용을 관찰하고 검증할 수 있습니다. [(예시)](/docs/testing-recipes.html#events) -UI 테스트의 많은 부분은 위의 설정으로 작성할 수 있습니다. jsdom에게 렌더링하는 테스트 러너로서, 브라우저 이벤트 시퀀스로 지정된 사용자 상호작용과 함께Jest를 사용하는 것은 act() 도우미에 의해 작동됩니다.[(예시)](/docs/testing-recipes.html) 예를 들어, 많은 React 자체 테스트는 이런 조합으로 작성됩니다. +UI 테스트의 많은 부분은 위의 설정으로 작성할 수 있습니다. jsdom에게 렌더링하는 테스트 러너로서, 브라우저 이벤트 시퀀스로 지정된 사용자 상호작용과 함께Jest를 사용하는 것은 `act()` 도우미에 의해 작동됩니다.[(예시)](/docs/testing-recipes.html) 예를 들어, 많은 React 자체 테스트는 이런 조합으로 작성됩니다. 만약 대부분의 브라우저별 동작을 테스트하고 레이아웃이나 실제 입력과 같은 네이티브 브라우저 동작을 요구하는 라이브러리를 작성하는 경우 [mocha](https://mochajs.org/)와 같은 프레임 워크를 사용할 수 있습니다. -DOM을 시뮬레이션*할 수 없는* 환경에서 (예를 들면, Node.js에서 React Native 컴포넌트 테스트), 엘리먼트와의 상호작용을 시뮬레이션하기 위해 [event simulation helpers](/docs/test-utils.html#simulate)를 사용할 수 있습니다. 다른 대안으로, [`@testing-library/react-native`](https://testing-library.com/docs/native-testing-library)의 `fireEvent` 헬퍼를 사용할 수 있습니다. +DOM을 시뮬레이션*할 수 없는* 환경에서 (예를 들면, Node.js에서 React Native 컴포넌트 테스트), 엘리먼트와의 상호작용을 시뮬레이션하기 위해 [이벤트 시뮬레이션 헬퍼](/docs/test-utils.html#simulate)를 사용할 수 있습니다. 다른 대안으로, [`@testing-library/react-native`](https://testing-library.com/docs/native-testing-library)의 `fireEvent` 헬퍼를 사용할 수 있습니다. [Cypress](https://www.cypress.io/), [puppeteer](https://github.com/GoogleChrome/puppeteer), [webdriver](https://www.seleniumhq.org/projects/webdriver/) 같은 프레임워크들은 [end-to-end 테스트](#end-to-end-tests-aka-e2e-tests)를 진행하기에 유용합니다. -### 모의 함수 {#mocking-functions} +### 함수 모의하기 {#mocking-functions} 테스트를 작성할 때, 우리는 테스트 환경 내부에서 동등성이 없는 우리의 코드 중 일부를 목아웃하고 싶어합니다(예를 들어, `navigator.onLine` 상태를 Node.js 내부에서 확인하는 것처럼). 테스트는 또한 일부 함수를 감시할 수 있으며 테스트의 다른 부분이 함수들과 어떻게 상호작용하는지를 관찰할 수 있습니다. 이는 이러한 함수들을 선택적으로 시험 친화적인 버전으로 모의할 수 있다는 점에서 유용합니다. -모의 함수는 특히 데이터를 불러올 때 유용합니다. 실제 API 종단점으로부터 발생하는 느려짐과 손상을 방지하기 위해 테스트에 "가짜"데이터를 사용하는 것이 바람직한 방법입니다 [(예시)](/docs/testing-recipes.html#data-fetching). 이는 테스트를 예측 가능하게 만들어줍니다. [Jest](https://jestjs.io/)와 [sinon](https://sinonjs.org/)과 같은 라이브러리들은 모의 함수들을 지원합니다. 엔드 투 엔드 테스트의 경우 네트워크를 모사하는 것은 어려울 수 있지만, 실제 API 엔드포인트를 테스트하기를 원할 수도 있습니다. +모의 함수는 특히 데이터를 불러올 때 유용합니다. 실제 API 종단점으로부터 발생하는 느려짐과 손상을 방지하기 위해 테스트에 "가짜"데이터를 사용하는 것이 바람직한 방법입니다 [(예시)](/docs/testing-recipes.html#data-fetching). 이는 테스트를 예측 가능하게 만들어줍니다. [Jest](https://jestjs.io/)와 [sinon](https://sinonjs.org/)과 같은 라이브러리들은 모의 함수들을 지원합니다. 엔드 투 엔드 테스트의 경우 네트워크를 모사하는 것은 어려울 수 있지만, 실제 API 엔드포인트를 테스트하기를 원할 수도 있습니다. -### 모의 모듈 {#mocking-modules} +### 모듈 모의하기 {#mocking-modules} -일부 컴포넌트는 테스트 환경에서 잘 작동하지 않거나 테스트에 필수적이지 않은 모듈에 대한 의존성을 가지고 있습니다. 적절한 교체를 통해 이러한 모듈을 선택적으로 모의하는 것이 유용할 수 있습니다 [(예시)](/docs/testing-recipes.html#mocking-modules). +일부 컴포넌트는 테스트 환경에서 잘 작동하지 않거나 테스트에 필수적이지 않은 모듈에 대한 의존성을 가지고 있습니다. 적절한 교체를 통해 이러한 모듈을 선택적으로 모의하는 것이 유용할 수 있습니다 [(예시)](/docs/testing-recipes.html#mocking-modules). Node.js에서 Jest같은 러너는 [모의 모듈을 지원합니다](https://jestjs.io/docs/en/manual-mocks). 또한 [mock-require](https://www.npmjs.com/package/mock-require) 라이브러리도 사용할 수 있습니다. -### 모의 타이머 {#mocking-timers} +### 타이머 모의하기 {#mocking-timers} -컴포넌트는 setTimeout, setInterval, Data.now와 같은 시간을 기반으로한 함수를 사용할 수 있습니다. 테스트 환경에서, 이러한 함수들을 수동으로 발전할 수 있는 대체품으로 모의하는 것이 유용할 수 있습니다. 이것은 테스트가 빨리 진행되도록 하는 데 좋다! 타이머에 의존하는 테스트는 여전히 순서대로 해결되지만 더 빨리 해결됩니다[(예시)](https://github.com/reactjs/ko.reactjs.org/blob/master/docs/testing-recipes.html#timers). [Jest](https://jestjs.io/docs/en/timer-mocks), [sinon](https://sinonjs.org/releases/v7.3.2/fake-timers/), [lolex](https://github.com/sinonjs/lolex)를 포함한 대부분의 프레임워크는 테스트에서 타이머를 모의할 수 있게 해줍니다. +컴포넌트는 `setTimeout`, `setInterval`, `Data.now`와 같은 시간을 기반으로한 함수를 사용할 수 있습니다. 테스트 환경에서, 이러한 함수들을 수동으로 발전할 수 있는 대체품으로 모의하는 것이 유용할 수 있습니다. 이것은 테스트가 빨리 진행되도록 하는 데 좋다! 타이머에 의존하는 테스트는 여전히 순서대로 해결되지만 더 빨리 해결됩니다 [(예시)](https://github.com/reactjs/ko.reactjs.org/blob/master/docs/testing-recipes.html#timers). [Jest](https://jestjs.io/docs/en/timer-mocks), [sinon](https://sinonjs.org/releases/v7.3.2/fake-timers/), [lolex](https://github.com/sinonjs/lolex)를 포함한 대부분의 프레임워크는 테스트에서 타이머를 모의할 수 있게 해줍니다. 가끔, 모의 타이머를 원하지 않는 경우가 있을 수 있기도 합니다. 예를 들어, 애니메이션을 테스트하거나, 또는 (API 속도 제한 장치와 같은) 타이밍에 민감한 종단점과의 상호작용을 하는 경우가 있습니다. 타이머 모의가 있는 라이브러리는 테스트/묶음별로 활성화 및 비활성화할 수 있으므로 이러한 테스트 실행 방법을 명시적으로 선택할 수 있습니다.