Skip to content

Commit d0616c6

Browse files
ragubyunragubyun
committed
Translate into Korean 1.9
1 parent f127f4c commit d0616c6

File tree

1 file changed

+26
-29
lines changed

1 file changed

+26
-29
lines changed

‎readme.kr.md

Lines changed: 26 additions & 29 deletions
Original file line numberDiff line numberDiff line change
@@ -99,9 +99,9 @@ JavaScript 및 Node.js에 대한 A부터 Z까지의 믿음직한 가이드입니
9999

100100
<br/>
101101

102-
**👇 주의:** 각 글에는 코드 예제가 있으며 때로는 이미지도 있습니다. 클릭하여 확장
102+
**👇 주의:** 각 글에는 예제 코드가 있으며 때로는 이미지도 있습니다. 클릭하여 확장
103103

104-
<details><summary>✏ <b>코드 예제</b></summary>
104+
<details><summary>✏ <b>예제 코드</b></summary>
105105

106106
<br/>
107107

@@ -149,7 +149,7 @@ describe('제품 서비스', function() {
149149

150150
<br/>
151151

152-
<details><summary>✏ <b>코드 예제</b></summary>
152+
<details><summary>✏ <b>예제 코드</b></summary>
153153

154154
<br/>
155155

@@ -203,7 +203,7 @@ test('프리미엄으로 분류해야 합니다.', () => {
203203

204204
<br/>
205205

206-
<details><summary>✏ <b>코드 예제</b></summary><br/>
206+
<details><summary>✏ <b>예제 코드</b></summary><br/>
207207

208208
![](https://img.shields.io/badge/🔧%20Example%20using%20Mocha-blue.svg
209209
"Examples with Mocha & Chai") ![](https://img.shields.io/badge/🔧%20Example%20using%20Jest-blue.svg
@@ -260,7 +260,7 @@ it("관리자 요청이 들어오면 정렬된 관리자 목록만 결과에 포
260260

261261
<br/>
262262

263-
<details><summary>✏ <b>코드 예제</b></summary>
263+
<details><summary>✏ <b>예제 코드</b></summary>
264264

265265
<br/>
266266

@@ -309,7 +309,7 @@ it("화이트박스 테스트: 내부 method가 VAT 0을 받으면 0을 반환
309309

310310
<br/>
311311

312-
<details><summary>✏ <b>코드 예제</b></summary>
312+
<details><summary>✏ <b>예제 코드</b></summary>
313313

314314
<br/>
315315

@@ -356,7 +356,7 @@ it("유효한 제품을 삭제하려고 할 때, 메일을 보낸다", async ()
356356

357357
<br/>
358358

359-
<details><summary>✏ <b>코드 예제</b></summary>
359+
<details><summary>✏ <b>예제 코드</b></summary>
360360

361361
<br/>
362362

@@ -415,7 +415,7 @@ it("더 나은 것: 유효한 제품이 추가된다면, 성공을 얻는다.",
415415

416416
<br/>
417417

418-
<details><summary>✏ <b>코드 예제</b></summary>
418+
<details><summary>✏ <b>예제 코드</b></summary>
419419

420420
<br/>
421421

@@ -457,7 +457,7 @@ describe('Product service', () => {
457457

458458
<br/>
459459

460-
<details><summary>✏ <b>코드 예제</b></summary>
460+
<details><summary>✏ <b>예제 코드</b></summary>
461461

462462
<br/>
463463

@@ -514,51 +514,50 @@ expect(menu).toMatchInlineSnapshot(`
514514

515515
<br/><br/>
516516

517-
## ⚪ ️1.9 Avoid global test fixtures and seeds, add data per-test
518-
519-
:white_check_mark: **Do:** Going by the golden rule (bullet 0), each test should add and act on its own set of DB rows to prevent coupling and easily reason about the test flow. In reality, this is often violated by testers who seed the DB with data before running the tests ([also known as ‘test fixture’](https://en.wikipedia.org/wiki/Test_fixture)) for the sake of performance improvement. While performance is indeed a valid concern — it can be mitigated (see “Component testing” bullet), however, test complexity is a much painful sorrow that should govern other considerations most of the time. Practically, make each test case explicitly add the DB records it needs and act only on those records. If performance becomes a critical concern — a balanced compromise might come in the form of seeding the only suite of tests that are not mutating data (e.g. queries)
520-
<br/>
517+
## ⚪ ️ 1.9 테스트 데이터를 글로벌로 하지말고 테스트별로 따로 추가하라.
521518

519+
:white_check_mark: **이렇게 해라:** 황금률에 따르면(섹션 0), 각 테스트는 커플링을 방지하고 테스트 흐름을 쉽게 추론하기 위해 자체 DB 데이터를 추가하고 실행해야 합니다. 실제로 성능 향상(테스트를 실행하기 전에 DB 데이터를 준비(['테스트 픽스쳐'라고도 합니다](https://en.wikipedia.org/wiki/Test_fixture)))을 위해 이를 위반하는 테스터들이 많습니다. 성능은 실제로 유효한 문제이지만 완화될 수 있습니다(2.2 컴포넌트 테스트 참고). 그러나 테스트 복잡성은 대부분의 다른 고려사항들을 통제해야 하는 고통을 수반합니다. 각 테스트에 필요한 DB 레코드를 명시적으로 추가하고, 해당 데이터에 대해서만 테스트를 수행하십시오. 성능이 중요한 문제가 되는 경우 - 데이터를 변경하지 않는 테스트 모음(예: 쿼리)에 대해서 데이터를 준비하는 형태로 타협할 수 있습니다.
522520

523-
❌ **Otherwise:** Few tests fail, a deployment is aborted, our team is going to spend precious time now, do we have a bug? let’s investigate, oh no — it seems that two tests were mutating the same seed data
521+
<br/>
524522

523+
❌ **그렇지 않으면:** 테스트 실패, 배포 중단으로 팀원들이 귀중한 시간을 소비할 것입니다. 버그가 있습니까? 조사해보니 '없습니다' - 두 테스트에서 동일한 테스트 데이터를 변겨안 것으로 보입니다.
525524

526525
<br/>
527526

528-
<details><summary>✏ <b>Code Examples</b></summary>
527+
<details><summary>✏ <b>예제 코드</b></summary>
529528

530529
<br/>
531530

532-
### :thumbsdown: Anti Pattern Example: tests are not independent and rely on some global hook to feed global DB data
531+
### :thumbsdown: 올바르지 않은 예: 테스트는 독립적이지 않으며 글로벌 훅에 의한 DB 데이터에 의존
533532

534533
![](https://img.shields.io/badge/🔧%20Example%20using%20Mocha-blue.svg
535534
"Examples with Jest")
536535

537536
```javascript
538537
before(() => {
539-
//adding sites and admins data to our DB. Where is the data? outside. At some external json or migration framework
538+
// 사이트 및 관리자 데이터를 DB에 추가. 데이터는 어디에 있습니까? 외부에. 외부 JSON 또는 마이그레이션 프레임워크에
540539
await DB.AddSeedDataFromJson('seed.json');
541540
});
542-
it("When updating site name, get successful confirmation", async () => {
543-
//I know that site name "portal" exists - I saw it in the seed files
541+
it("사이트 이름을 업데이트 할 때, 성공을 확인한다.", async () => {
542+
// 사이트 이름 "portal"이 존재한다는 것을 알고있습니다. 시드파일에서 봤습니다.
544543
const siteToUpdate = await SiteService.getSiteByName("Portal");
545544
const updateNameResult = await SiteService.changeName(siteToUpdate, "newName");
546545
expect(updateNameResult).to.be(true);
547546
});
548-
it("When querying by site name, get the right site", async () => {
549-
//I know that site name "portal" exists - I saw it in the seed files
547+
it("사이트 이름을 쿼리할 때, 올바른 사이트 이름을 얻는다.", async () => {
548+
// 사이트 이름 "portal"이 존재한다는 것을 알고있습니다. 시드파일에서 봤습니다.
550549
const siteToCheck = await SiteService.getSiteByName("Portal");
551-
expect(siteToCheck.name).to.be.equal("Portal"); //Failure! The previous test change the name :[
550+
expect(siteToCheck.name).to.be.equal("Portal"); // 실패! 이전 테스트에서 이름이 변경되었습니다. ㅠㅠ
552551
});
553-
554552
```
553+
555554
<br/>
556555

557-
### :clap: Doing It Right Example: We can stay within the test, each test acts on its own set of data
556+
### :clap: 올바른 예: 우리는 테스트 내부에만 머물 수 있으며, 각 테스트는 자체 데이터 세트에서 동작합니다.
558557

559558
```javascript
560-
it("When updating site name, get successful confirmation", async () => {
561-
//test is adding a fresh new records and acting on the records only
559+
it("사이트 이름을 업데이트 할 때, 성공을 확인한다.", async () => {
560+
// 테스트는 새로운 레코드를 새로 추가하고 해당 레코드에 대해서만 동작합니다.
562561
const siteUnderTest = await SiteService.addSite({
563562
name: "siteForUpdateTest"
564563
});
@@ -567,13 +566,11 @@ it("When updating site name, get successful confirmation", async () => {
567566

568567
expect(updateNameResult).to.be(true);
569568
});
570-
571569
```
572570

573571
</details>
574572

575-
576-
<br/>
573+
<br/><br/>
577574

578575
## ⚪ ️ 1.10 Don’t catch errors, expect them
579576
:white_check_mark: **Do:** When trying to assert that some input triggers an error, it might look right to use try-catch-finally and asserts that the catch clause was entered. The result is an awkward and verbose test case (example below) that hides the simple test intent and the result expectations

0 commit comments

Comments
 (0)