Merge pull request #2 from jaehwang/kr-review
Update Korean version primer.md
This commit is contained in:
commit
59b905e0b9
@ -8,27 +8,33 @@ googletest는 Google Testing Technology Team 주도로 개발이 시작되었습
|
|||||||
|
|
||||||
1. 테스트는 *독립적이고 반복적으로* 수행될 수 있어야 합니다. 테스트들이 서로 영향을 받는다면 디버깅이 어려워질 것입니다. googletest는 각 테스트를 서로 다른 객체object에서 실행함으로써 테스트들을 격리시킵니다. 한 테스트가 실패했을 때 googletest로 그것만 따로 실행해서 디버깅을 빨리 할 수 있습니다.
|
1. 테스트는 *독립적이고 반복적으로* 수행될 수 있어야 합니다. 테스트들이 서로 영향을 받는다면 디버깅이 어려워질 것입니다. googletest는 각 테스트를 서로 다른 객체object에서 실행함으로써 테스트들을 격리시킵니다. 한 테스트가 실패했을 때 googletest로 그것만 따로 실행해서 디버깅을 빨리 할 수 있습니다.
|
||||||
2. 테스트는 *잘 정리되어 있어야* 하고 테스트한 코드의 구조도 반영해야 합니다. googletest는 관련있는 테스트를 테스트 스위트test suite로 묶어 데이터와 서브루틴subroutine을 공유할 수 있게 합니다. 이 보편적인 형태는 알아보기도 쉽고 테스트 유지보수도 쉽게 만듭니다. 이런 일관성은 사람들이 프로젝트를 바꿔 새로운 코드에서 일을 시작할 때 특히 도움이 됩니다.
|
2. 테스트는 *잘 정리되어 있어야* 하고 테스트한 코드의 구조도 반영해야 합니다. googletest는 관련있는 테스트를 테스트 스위트test suite로 묶어 데이터와 서브루틴subroutine을 공유할 수 있게 합니다. 이 보편적인 형태는 알아보기도 쉽고 테스트 유지보수도 쉽게 만듭니다. 이런 일관성은 사람들이 프로젝트를 바꿔 새로운 코드에서 일을 시작할 때 특히 도움이 됩니다.
|
||||||
3. 테스트는 *이식성*과 *재사용성*이 있어야 합니다. Google에는 플랫폼 중립적인 코드가 아주 많기 때문에 테스트코드 또한 플랫폼 중립적이어야 합니다. googletest는 여러 운영체제에서 여러 컴파일러와 예외exception가 활성화되었든 아니든 동작하므로 googletest는 다양한 구성으도 동작할 수 있습니다.
|
3. 테스트는 *이식성*과 *재사용성*이 있어야 합니다. Google에는 플랫폼 중립적인 코드가 아주 많기 때문에 테스트코드 또한 플랫폼 중립적이어야 합니다. googletest는 여러 운영체제에서 여러 컴파일러와 예외exception가 활성화되었든 아니든 동작하므로 googletest는 다양한 구성configuration으로 동작할 수 있습니다.
|
||||||
4. 테스트는 실패했을 때, 그 문제에 대해 가능한 많은 *정보를 제공해야 합니다.* googletest가 여러개의 Test를 수행하는 동안에는 1개의 Test가 실패하더라도 나머지 Test들은 계속해서 수행합니다. 또한, 실패한 Test가 non-fatal failure로 지정되었다면 해당 Test 자체도 중단하지 않습니다. 이러한 설계의 장점은 한 번의 수행으로도 여러개의 bug를 찾아내고 개선할 수 있다는 것입니다.
|
4. 테스트가 실패했을 때 테스트 문제에 대해 가능한 많은 *정보를 제공해야 합니다.* googletest는 첫번째 테스트 실패에서 중단되지 않습니다. 해당 테스트만 먼추고 다음으로 진행합니다. non-fatal failure를 리포트 하고 계속 진행하게 테스트를 설정할 수도 있습니다. 이러한 설계의 장점은 한 번의 run-edit-compile cyclle로도 여러 개의 bug를 찾아내고 개선할 수 있다는 것입니다.
|
||||||
5. 테스트 프레임워크는 테스트를 구현하는 사람이 실제 구현에만 집중할 수 있도록 도와줘야 합니다. googletest는 정의된 모든 Test를 자동으로 찾아서 실행해주기 때문에 사용자가 하나하나 찾아서 실행할 필요가 없습니다.
|
5. 테스팅 프레임워크는 테스트를 구현하는 사람이 실제 구현에만 집중할 수 있도록 도와줘야 합니다. googletest는 정의된 모든 Test를 자동으로 찾아서 실행해주기 때문에 사용자가 하나하나 찾아서 실행할 필요가 없습니다.
|
||||||
6. 테스트는 *빨라야 합니다.* googletest는 set-up/tear-down을 제공함으로서 여러 Test가 공유해야할 내용을 한번의 구현만으로도 재사용될 수 있도록 했습니다.
|
6. 테스트는 *빨라야 합니다.* googletest를 쓰면 테스트 간의 공유 자원을 재사용 할 수 있고, 테스트 간 상호 의존 없이 설정/해체을 한 번만 부담하면 됩니다.
|
||||||
|
|
||||||
googletest가 xUnit architecture를 기반으로 설계되었기 때문에 JUnit, PyUnit과 같은 xUnit계열 테스트 프레임워크를 사용해본 경험이 있다면 빠르게 적응할 수 있습니다. 물론, 그러한 경험이 없더라도 기초적인 것을 배우고 구현하는 데에는 10분이면 충분합니다.
|
googletest가 xUnit architecture를 기반으로 설계되었기 때문에 JUnit, PyUnit과 같은 xUnit계열 테스트 프레임워크를 사용해본 경험이 있다면 빠르게 적응할 수 있습니다. 물론, 그러한 경험이 없더라도 기초적인 것을 배우고 구현하는 데에는 10분이면 충분합니다. 그러니 같이 시작해 봅시다!
|
||||||
|
|
||||||
## 용어 구분하기
|
## 명명법 주의
|
||||||
|
|
||||||
*Note:* *Test*, *Test Case*, *Test Suite*과 같은 용어를 사용함에 있어서 googletest와 [ISTQB](http://www.istqb.org/) 간에 정의가 다르기 때문에 주의가 필요합니다.
|
*Note:* *테스트Test*, *테스트 케이스Test Case*, *테스트 스위트Test Suite*같은 용어의 정의 차이로 인해 혼란이 있을 수 있습니다.
|
||||||
|
|
||||||
googletest는 개별 테스트를 가리키는 용어로서 Test를 사용해왔고 여러 Test의 묶음을 의미하는 용어로 Test Case를 사용해왔습니다. 그러나 ISTQB를 비롯한 표준기관에서는 여러 Test의 묶음을 의미하는 용어로 [*Test Suite*](https://glossary.istqb.org/en/search/test%20suite)를 채택하고 있어서 혼란이 발생하곤 했습니다.
|
역사적으로 googletest는 연관된 테스트들의 묶음이라는 뜻으로 *테스트 케이스*를 사용하기 시작했습니다. 반면에 [ISTQB](http://www.istqb.org/)를 비롯한 표준기관에서는 [*테스트 스위트*][istqb test suite]를 이런 의미로 사용합니다.
|
||||||
|
|
||||||
즉, googletest의 Test라는 용어를 ISTQB의 [*Test Case*](https://glossary.istqb.org/en/search/test%20case)와 동일한 의미로 사용하려고 해도 원래 googletest에서 Test 묶음을 의미하는 용어였던 Test Case와 충돌이 발생해서 문제가 되었던 것입니다. 결국 googletest는 *Test Case*라는 용어를 *Test Suite*으로 바꾸기로 결정했으며 *TestCase*로 시작하는 API들을 *TestSuite*으로 변경하는 과정에 있습니다.
|
googletest에서 사용되는 관련 용어 *테스트*는 ISTQB 등의 용어로는 [*테스트 케이스*][istqb test case]에 해당됩니다.
|
||||||
|
|
||||||
다만, 그러한 변경작업이 완료된 것은 아니기 때문에 이런 부분을 유념하여 용어를 구분하는데 문제가 없기를 바랍니다. 정리하면 개별테스트에 대해서는 Test, Test Case,`TEST()`가 사용되며 Test의 묶음에 대해서는 Test Suite을 사용하지만 일부 정리안된 Test Case가 남아있을 수도 있습니다.
|
*테스트*라는 용어는 일반적으로 충분히 넓은 뜻으로 받아 들여져 ISTQB의 *테스트 케이스* 정의까지 포함하므로 큰 문제는 아닙니다. 그러나 구글 테스트Google Test에서 사용된 *테스트 케이스*라는 용어는 모순된 의미를 가져 혼란을 야기합니다.
|
||||||
|
|
||||||
Meaning | googletest Term | ISTQB Term
|
googletest는 *Test Case*라는 용어를 *Test Suite*로 바꾸기 시작했습니다. 선호하는 API는 *TestSuite*입니다. 이전의 TestCase API는 서서히 사용이 중단되고 리팩토링되고 있습니다.
|
||||||
|
|
||||||
|
그러니 용어들의 다른 의미에 주의해 주십시오.
|
||||||
|
|
||||||
|
의미 | googletest 용어 | [ISTQB](http://www.istqb.org/) 용어
|
||||||
------- | --------------- | -------------------------------------
|
------- | --------------- | -------------------------------------
|
||||||
클래스 또는 단일 function에 input을 주고 그 결과를 확인하는 단위 | TEST() | Test Case
|
특정 입력으로 프로그램을 실행하고 그 결과를 검증 | [TEST()](#간단한-테스트) | [Test Case][istqb test case]
|
||||||
바로 위에서 표현한 단위에 대한 묶음 | Test Case → Test Suite (변경 중) | Test Suite
|
|
||||||
|
[istqb test case]: http://glossary.istqb.org/en/search/test%20case
|
||||||
|
[istqb test suite]: http://glossary.istqb.org/en/search/test%20suite
|
||||||
|
|
||||||
## 기본 개념
|
## 기본 개념
|
||||||
|
|
||||||
@ -110,7 +116,7 @@ Argument가 변수형태라면 assertion코드가 수행되는 시점에 저장
|
|||||||
|
|
||||||
### String Comparison
|
### String Comparison
|
||||||
|
|
||||||
여기서는 C string을 비교하기 위한 assertion을 소개합니다. (만약, `string` object를 비교하고자 한다면 위에서 다룬 `EXPECT_EQ` `EXPECT_NE`를 사용하면 됩니다.)
|
여기서는 C string을 비교하기 위한 assertion을 소개합니다. (만약, `string` object를 비교하고자 한다면 위에서 다룬 `EXPECT_EQ`, `EXPECT_NE`를 사용하면 됩니다.)
|
||||||
|
|
||||||
| Fatal assertion | Nonfatal assertion | Verifies |
|
| Fatal assertion | Nonfatal assertion | Verifies |
|
||||||
| ------------------------------- | ------------------------------- | -------------------------------------------------------- |
|
| ------------------------------- | ------------------------------- | -------------------------------------------------------- |
|
||||||
|
Loading…
x
Reference in New Issue
Block a user