2010-03-07 3 views

답변

26

(... 바로 구글 테스트 문서에서)이 시도 : 예를 들어

FRIEND_TEST(TestCaseName, TestName); 

:

// foo.h 
#include <gtest/gtest_prod.h> 

// Defines FRIEND_TEST. 
class Foo { 
    ... 
private: 
    FRIEND_TEST(FooTest, BarReturnsZeroOnNull); 
    int Bar(void* x); 
}; 

// foo_test.cc 
... 
TEST(FooTest, BarReturnsZeroOnNull) { 
    Foo foo; 
    EXPECT_EQ(0, foo.Bar(NULL)); 
    // Uses Foo's private member Bar(). 
} 
+0

예를 들어 BarReturnsOneOnSth에 대한 다른 테스트가 있다면 어떨까요? 그 테스트를 위해 또 다른 FRIEND_TEST 선언을 추가해야합니까? – pajton

+1

예. 각 테스트는 기술적 인 수업이므로 한 번에 하나씩 친구가되어야합니다. – hobbit

+15

'Foo' 클래스의 헤더 파일에 googletest 헤더 파일을 포함시키지 않는 방법으로 어떻게 할 수 있습니까? –

19

나는이 오래지만 오늘 같은 대답을 찾고 있었다 알고있다. "gtest_prod.h"는 테스트 클래스를 참조하는 간단한 매크로를 소개합니다.

friend class FooTest_BarReturnsZeroOnNull_Test; 

각각의 테스트는 이전의 대답에 언급 한 바와 같이 자신의 클래스이기 때문에이 작동 :

#define FRIEND_TEST(test_case_name, test_name)\ 
friend class test_case_name##_##test_name##_Test 

그래서 FRIEND_TEST(FooTest, BarReturnsZeroOnNull);은 동일합니다.

+0

@DaveRuske 편집 자체에서 편집 내용을 설명하지 마십시오. 이것이 바로 편집 요약입니다. 문제가 6 자 제한 인 경우 본문의 어딘가에 ''을 추가 할 수 있습니다 (''은 주석이므로 보이지 않습니다). –

0

더 나은 전략은 단위 테스트 중 친구 테스트를 허용하지 않는 것입니다.

개인 멤버에 액세스하는 친구 테스트를 허용하면 관리하기 어려운 코드 기반이 될 수 있습니다. 구성 요소의 내부 구현 세부 정보가 리팩토링 될 때마다 중단되는 테스트는 원하는 결과가 아닙니다. 대신 공용 인터페이스를 통해 구성 요소를 테스트 할 수있는 디자인을 얻는 데 추가적인 노력을 기울이면 구성 요소의 공용 인터페이스가 업데이트 될 때마다 업데이트 만 필요한 테스트를 받게됩니다.

gtest/gtest_prod.h에 의존하는 테스트는 잘못된 디자인으로 간주되어야합니다.

+1

나는 이것이 논란의 여지가 있음을 잘 알고 있습니다. (논란의 여지가있는 답답한 배지 )를 얻었지만, 누군가이 관점을 가져 왔기 때문에 기쁩니다. 많은 사람들이 @Martin에 동의합니다! https://dzone.com/articles/principles-creating – pestophagous

관련 문제