구글 C++ 테스팅 프레임워크는 여러분이 더 나은 C++ 테스트들을 작성할 수 있도록 도와줍니다.
어떤 요소들이 좋은 테스트를 만드는지 그리고 어떻게 구글 C++ 테스팅 프레임워크가 적절한지 그 이유는 다음과 같습니다:
- 테스트들은 독립적이고 반복적이어야 합니다. 다른 테스트들의 결과로서 성공이나 실패한 임의의 테스트를 디버깅하는 것은 고통스럽습니다. 구글 C++ 테스팅 프레임워크는 서로 다른 객체에 대해서 그것들 각각마다 작동하기때문에 테스트들이 서로 독립적입니다. 임의의 테스트가 실패했을 때, 구글 C++ 테스팅 프레임워크는 여러분이 신속히 디버깅을 하기 위해서 그 테스트만 독립적으로 실행할 수 있도록 해줍니다.
- 테스트들은 잘 구성되어야하고 테스트되는 코드의 구조를 반영해야합니다. 구글 C++ 테스팅 프레임워크는 자료와 서브루틴들을 공유하는 연관된 테스트들을 테스트 케이스들로 그룹화합니다. 이러한 공통 패턴은 인지하기 쉽고 테스트들을 유지하기 쉽도록 해줍니다. 이러한 일관성은 사람들이 프로젝트들을 전환하고 새로운 코드 베이스위에서 다시 작업을 시작할 때 특히 유용합니다.
- 테스트들은 이식성이 좋고 재사용 가능해야 합니다. 오픈-소스 커뮤니티들은 플랫폼 중립적인 많은 코드들을 가지고 있고 그것들의 테스트들도 또한 플랫폼 중립적이어야 합니다. 구글 C++ 테스팅 프레임워크는 서로 다른 OS들, 서로 다른 컴파일러들(gcc, MSVC, 기타등등)에서 작동합니다. 그래서 구글 C++ 테스팅 프레임워크 테스트들은 여러 설정들에서 손쉽게 작동합니다.(알림 현재 릴리즈는 Linux에서만 빌드 스크립트들을 포함하고 있습니나. 현재 다른 플랫폼에 대한 스크립트들을 작업 중 입니다.)
- 테스트들이 실패했을 때, 테스트들은 문제에 대한 정보를 가능한 많이 제공해야합니다. 구글 C++ 테스팅 프레임워크는 첫 번째 테스트 실패에서 멈추지 않습니다. 대신, 현재 테스트만 중단하고 다음 테스트를 진행합니다. 또한 여러분이 치명적이지 않은 실패들을 보고하도록 테스트들을 설정할 수 있고 그러한 테스트들 이후에 현재 테스트가 진행됩니다. 따라서 여러분은 한번의 실행-수정-컴파일 사이클안에 여러 버그들을 발견하고 수정할 수 있습니다.
- 테스팅 프레임워크는 테스트 작성자들이 허드렛 일에서 해방시켜주고 그 테스트 내용에만 집중할 수 있도록 해줍니다. 구글 C++ 테스팅 프레임워크는 자동적으로 정의된 모든 테스트들을 기록해서 여러분이 테스트들을 실행하기 위해서 그것들을 애뮬레이션하는 것을 요구하지 않습니다.
- 테스트들은 신속해야합니다. 구글 C++ 테스팅 프레임워크를 사용함으로써, 여러분은 테스트들사이에 공유된 자원들을 재사용할 수 있으므로 각각에 의존적인 테스트들을 만들 필요없이 단 한번만 set-up/tear-down을 호출하면 됩니다.
알림 : 이하 Google C++ 테스팅 프레임워크를 구글 테스트라고 합니다.
새로운 테스트 프로젝트 설정하기
구글 테스트를 사용해서 테스트 프로그램을 작성하기 위해서, 여러분은 구글 테스트를 라이브러리로 컴파일하고 여러분의 테스트에 그것을 링크해야합니다. 우리는 몇몇 대표적인 빌드 시스템들(Visual Studio의 msvc, 맥 Xcode의 xcode, GNU make의 make, 볼랜드 C++ 빌더의 codegear, Scons의 scons그리고 구글 테스트 루트 디렉토리안에 자동화 스크립트 툴들)에 대한 빌드 파일들을 제공합니다. 만약 여러분의 빌드 시스템이 이러한 것들 중 하나가 아니라면, 여러분은 어떻게 구글 테스트가 컴파일되어야 하는지에 대해서 배우기 위해서 make/Makefile을 살펴볼 수 있습니다(기본적으로 여러분은 헤더 검색 경로로 GTEST_ROOT/include로 설정하고 src/gtest-all.cc를 컴파일하고 싶을 것입니다. 여기서 GTEST_ROOT는 구글 테스트의 루트 디렉토리입니다).
여러분이 구글 테스트 라이브러리를 컴파일한다면, 여러분의 테스트 프로그램에 대한 프로젝트를 생성하거나 타겟을 빌드할 수 있습니다. 테스트를 컴파일할 때, 컴파일러가
만약 여러분이 질문이 있다면, 어떻게 구글 테스트의 자체 테스트들이 빌드되는지 살펴보시고 그것들을 예제들로 사용하세요.
기본 개념들
구글 테스트를 사용할 때, 임의의 조건이 참인지 아닌지를 판별하는 구문들인 단정문들 작성함으로써, 시작합니다. 임의의 단정문의 결과는 성공, 치명적이지 않은 실패 또는 치명적인 실패일 수 있습니다. 만약 치명적인 실패가 발생한다면, 그것은 현재 함수를 중단합니다. 반대로 그렇지 않다면, 프로그램은 일반적으로 계속 진행됩니다.
테스트들이 테스트되는 코드의 행위를 검증하기 위해서 단정문들을 사용합니다. 만약 임의의 테스트가 충돌하거나 실패한 단정문을 가진다면, 그때 테스트는 실패한 것이고 그렇지 않다면, 성공한 것입니다.
테스트 케이스는 하나 이상의 테스트들을 포함합니다. 여러분은 테스트들을 테스트되는 코드의 구조를 반영하는 테스트 케이스들로 그룹화해야 합니다. 하나의 테스트 케이스안에 다수의 테스트들이 공통의 객체들과 서브루틴들을 공유해야할 필요가 있을 때, 여러분은 그것들을 하나의 테스트 픽스쳐 클래스에 담을 수 있습니다.
테스트 프로그래은 다수의 테스트 케이스들을 포함할 수 있습니다.
우리는 이제 개별적인 단정문 수준에서 시작해서 테스트들과 테스트 케이스들 점진적으로 구성하면서 하나의 테스트 프로그램을 어떻게 작성할 수 있는지 설명할 것 입니다.
단정문들
구글 테스트 단정문들은 함수 호출들과 유사한 매크로들입니다. 여러분은 클래스 또는 함수의 행위에 대한 단정문들을 작성함으로써 그것들을 테스트합니다. 하나의 단정문이 실패했을 때, 구글 테스트는 실패 메세지와 함께 그 단정문의 소스 파일과 행 번호를 출력합니다. 여러분은 또한 구글 테스트의 메세지에 추가적으로 독자적인 실패 메세지를 제공할 수 있습니다.
단정문들은 동일한 테스트를 수행하는 쌍들로 나오기도 하지만, 그 함수에 대해 서로 다른 효과를 가집니다. ASSERT_* 버전들은 실패했을 때, 치명적인 실패를 생성하고 그 함수를 중단합니다. EXPECT_* 버전들은 치명적이지 않은 실패를 생성하지만, 그 함수를 중단하지는 않습니다. 보통 EXPECT_*를 더 선호하기 때문에, 한번 테스트에 하나 이상의 실패들이 보고될 수 있습니다. 하지만, 단정문이 실패했을 때, 더 이상 진행할 필요가 없을 경우라면, 여러분은 ASSERT_*를 사용합니다.
실패된 ASSERT_*는 즉시적으로 현재 함수로 부터 반환되기 때문에, 그 이후로 나오는 정리 코드들은 생략될 수도 있습니다. 이러한 이유로 공간 누수가 발생할 수도 있습니다. 그 누수의 현상에 따라서, 수정할 가치가 있을 수도 없을 수도 있습니다 - 그래서 단정 오류에 추가적으로 힙 오류를 체크할 것인가를 고려해야합니다.
독자적인 실패 메세지를 제공하려면, 단순히 그 메세지를 << 연산자나 연속적인 << 연산자를 사용해서 그 매크로에 메세지를 스트리밍합니다. 예를 들면,
ASSERT_EQ(x.size(), y.size()) << "Vectors x and y are of unequal length";C 문자열과 string 객체와 같이 ostream으로 스트림될 수 있는 어떤 것이라도 단정 매크로로 스트림될 수 있습니다. 만약 와이드 string(윈도우즈 유니코드 모드에서 wchar_t*, TCHAR*나 std::wstring)이 단정문으로 스트림된다면, 그것은 출력될 때 UTF-8으로 변환될 것 입니다.
for (int i = 0; i < x.size(); ++i) {
EXPECT_EQ(x[i], y[i]) << "Vectors x and y differ at index " << i;
}
기본적인 단정문들
현재 프로젝트의 TDD용 테스팅 프레임워크로 구글테스트를 낙점. 필독 문서라고 볼 수 있는 GoogleTestPrimer를 번역해서 회사 개발자들과 공유하려고 작업 중이다.
답글삭제