Merge pull request #2 from jaehwang/kr-review
Update Korean version primer.md
This commit is contained in:
Hyuk Myeong
GitHub
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
|
||||||
|
|
||||||
## 기본 개념
|
## 기본 개념
|
||||||
|
|
||||||
@ -102,7 +108,7 @@ Argument가 변수형태라면 assertion코드가 수행되는 시점에 저장
|
|||||||
|
|
||||||
만약 부동소수점 타입을 확인하고자 할 때는 반올림관련 문제가 있기 때문에 별도의 assertion을 사용해야 합니다. 자세한 내용은 [Advanced googletest Topics](advanced.md#floating-point-비교하기)를 참조하세요.
|
만약 부동소수점 타입을 확인하고자 할 때는 반올림관련 문제가 있기 때문에 별도의 assertion을 사용해야 합니다. 자세한 내용은 [Advanced googletest Topics](advanced.md#floating-point-비교하기)를 참조하세요.
|
||||||
|
|
||||||
이 섹션의 macro들은 narrow string(string), wide string(wstring) 양쪽 모두에 대해서 잘 동작합니다.
|
이 섹션의 macro들은 narrow string(string), wide string(wstring) 양쪽 모두에 대해서 잘 동작합니다.
|
||||||
|
|
||||||
**Availability**: Linux, Windows, Mac.
|
**Availability**: Linux, Windows, Mac.
|
||||||
|
|
||||||
@ -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 |
|
||||||
| ------------------------------- | ------------------------------- | -------------------------------------------------------- |
|
| ------------------------------- | ------------------------------- | -------------------------------------------------------- |
|
||||||
@ -260,7 +266,7 @@ TEST_F(QueueTest, DequeueWorks) {
|
|||||||
}
|
}
|
||||||
```
|
```
|
||||||
|
|
||||||
위 코드를 보면 `ASSERT_*`와 `EXPECT_*`를 모두 사용하고 있습니다. `EXPECT_*`는 failure가 발생해도 계속 진행하기 때문에 Test를 한 번 실행하면서 최대한 많은 문제를 찾아내고 싶을 때 주로 사용합니다. 반면에 failure가 발생했을 때에 Test를 계속 진행하는 것이 아무런 의미가 없는 경우에는 `ASSERT_*`를 사용해서 바로 종료시키는 것이 좋습니다. 예를 들어, `DequeueWorks`의 `ASSERT_NE(n, nullptr)` 부분을 보면 `n`이 `nullptr`이라면 그 다음에 나오는 `EXPECT_EQ(*n, 1);`에서 segfault가 발생할 것이 자명하기 때문에 테스트를 진행하는 것은 의미가 없어집니다. 바로 이런 경우에는 Test를 중단시키는 것이 논리적으로 맞습니다.
|
위 코드를 보면 `ASSERT_*`와 `EXPECT_*`를 모두 사용하고 있습니다. `EXPECT_*`는 failure가 발생해도 계속 진행하기 때문에 Test를 한 번 실행하면서 최대한 많은 문제를 찾아내고 싶을 때 주로 사용합니다. 반면에 failure가 발생했을 때에 Test를 계속 진행하는 것이 아무런 의미가 없는 경우에는 `ASSERT_*`를 사용해서 바로 종료시키는 것이 좋습니다. 예를 들어, `DequeueWorks`의 `ASSERT_NE(n, nullptr)` 부분을 보면 `n`이 `nullptr`이라면 그 다음에 나오는 `EXPECT_EQ(*n, 1);`에서 segfault가 발생할 것이 자명하기 때문에 테스트를 진행하는 것은 의미가 없어집니다. 바로 이런 경우에는 Test를 중단시키는 것이 논리적으로 맞습니다.
|
||||||
|
|
||||||
정리해보면 위의 test program을 실행하면 아래와 같은 일들이 일어나게 됩니다.
|
정리해보면 위의 test program을 실행하면 아래와 같은 일들이 일어나게 됩니다.
|
||||||
|
|
||||||
@ -277,7 +283,7 @@ TEST_F(QueueTest, DequeueWorks) {
|
|||||||
|
|
||||||
`TEST()` 및 `TEST_F()`를 통해 정의된 Test들은 googletest에 등록되어 내부적으로 관리하게 됩니다. 그렇게 등록된 Test들은 googletest가 자동으로 실행해 주기 때문에 다른 C++언어의 테스트 프레임워크와 달리 각각의 Test를 별도로 실행할 필요가 없습니다.
|
`TEST()` 및 `TEST_F()`를 통해 정의된 Test들은 googletest에 등록되어 내부적으로 관리하게 됩니다. 그렇게 등록된 Test들은 googletest가 자동으로 실행해 주기 때문에 다른 C++언어의 테스트 프레임워크와 달리 각각의 Test를 별도로 실행할 필요가 없습니다.
|
||||||
|
|
||||||
Test program을 구현한 후 `main()` function에서 `RUN_ALL_TESTS()`만 호출하면 등록된 모든 Test를 실행해줍니다. ` RUN_ALL_TESTS()`는 `TEST()` 및 `TEST_F()`를 사용한 모든 Test를 수행하고 성공하면 `0`을 반환하고 실패하면 `1` 또는 다른 값을 반환합니다.
|
Test program을 구현한 후 `main()` function에서 `RUN_ALL_TESTS()`만 호출하면 등록된 모든 Test를 실행해줍니다. ` RUN_ALL_TESTS()`는 `TEST()` 및 `TEST_F()`를 사용한 모든 Test를 수행하고 성공하면 `0`을 반환하고 실패하면 `1` 또는 다른 값을 반환합니다.
|
||||||
|
|
||||||
`RUN_ALL_TESTS()`을 수행하면 아래와 같은 동작들이 일어나게 됩니다.
|
`RUN_ALL_TESTS()`을 수행하면 아래와 같은 동작들이 일어나게 됩니다.
|
||||||
|
|
||||||
@ -293,7 +299,7 @@ Test program을 구현한 후 `main()` function에서 `RUN_ALL_TESTS()`만 호
|
|||||||
주의할 점은 어떤 Test를 진행하다가 fatal failure가 발생했다면 그 다음 단계들은 수행하지 않고 다음 Test로 넘어간다는 점입니다.
|
주의할 점은 어떤 Test를 진행하다가 fatal failure가 발생했다면 그 다음 단계들은 수행하지 않고 다음 Test로 넘어간다는 점입니다.
|
||||||
|
|
||||||
> IMPORTANT: `RUN_ALL_TESTS()`는 `main()`의 맨 끝에서 호출되고 또 반환되어야만 합니다. 그렇지 않으면 compile error가 발생합니다. googletest가 이렇게 설계된 이유는 자동화된 testing service 환경에서 test program의 성공여부를 stdout/stderr이 아닌 exit code를 통해서 자동으로 확인할 수 있도록 하기 위함입니다. 이를 위해서 `main()`은 반드시 `RUN_ALL_TESTS()`를 반환해야 합니다.
|
> IMPORTANT: `RUN_ALL_TESTS()`는 `main()`의 맨 끝에서 호출되고 또 반환되어야만 합니다. 그렇지 않으면 compile error가 발생합니다. googletest가 이렇게 설계된 이유는 자동화된 testing service 환경에서 test program의 성공여부를 stdout/stderr이 아닌 exit code를 통해서 자동으로 확인할 수 있도록 하기 위함입니다. 이를 위해서 `main()`은 반드시 `RUN_ALL_TESTS()`를 반환해야 합니다.
|
||||||
>
|
>
|
||||||
> 또한, `RUN_ALL_TESTS()`는 딱 한 번만 호출되어야 합니다. 이 function을 두 번 이상 호출하게 되면 몇몇 advanced googletest features(예: thread-safe [death tests](http://collab.lge.com/main/display/SEETVTEST/Google+Test%3A+Advanced#DeathTests))와의 출동이 발생하기 때문에 지원하지 않고 있습니다.
|
> 또한, `RUN_ALL_TESTS()`는 딱 한 번만 호출되어야 합니다. 이 function을 두 번 이상 호출하게 되면 몇몇 advanced googletest features(예: thread-safe [death tests](http://collab.lge.com/main/display/SEETVTEST/Google+Test%3A+Advanced#DeathTests))와의 출동이 발생하기 때문에 지원하지 않고 있습니다.
|
||||||
|
|
||||||
**Availability**: Linux, Windows, Mac.
|
**Availability**: Linux, Windows, Mac.
|
||||||
|
|||||||
Loading…
x
Reference in New Issue
Block a user