나는 이것이 논쟁의 여지가 있다는 것을 알고 있지만 이것이 최선의 선택이라고 가정 해 봅시다. 이 작업을 수행하는 실제 기술이 무엇인지 궁금합니다. 내가 보는 접근 방식은 다음과 같습니다.
1) 내가 시험하고 싶은 수업의 친구 수업을하십시오.
2) 친구 클래스에서 테스트 된 클래스의 개인 메소드를 호출하는 공개 메소드를 작성하십시오.
3) 친구 수업의 공개 방법을 테스트하십시오.
위의 단계를 설명하는 간단한 예는 다음과 같습니다.
#include <iostream>
class MyClass
{
friend class MyFriend; // Step 1
private:
int plus_two(int a)
{
return a + 2;
}
};
class MyFriend
{
public:
MyFriend(MyClass *mc_ptr_1)
{
MyClass *mc_ptr = mc_ptr_1;
}
int plus_two(int a) // Step 2
{
return mc_ptr->plus_two(a);
}
private:
MyClass *mc_ptr;
};
int main()
{
MyClass mc;
MyFriend mf(&mc);
if (mf.plus_two(3) == 5) // Step 3
{
std::cout << "Passed" << std::endl;
}
else
{
std::cout << "Failed " << std::endl;
}
return 0;
}
편집하다:
토론에서 사람들이 내 코드베이스에 대해 궁금해하는 답변 중 하나를 따르는 것을 볼 수 있습니다.
내 클래스에는 다른 메소드에 의해 호출되는 메소드가 있습니다. 이러한 메소드 중 어느 것도 클래스 외부에서 호출해서는 안되므로 개인용이어야합니다. 물론 그것들은 하나의 방법으로 들어갈 수 있지만 논리적으로는 훨씬 더 분리되어 있습니다. 이러한 방법은 단위 테스트를 보장하기에 충분히 복잡하며 성능 문제로 인해 이러한 방법을 리팩토링해야 할 가능성이 높으므로 리팩토링이 아무 것도 깨지지 않도록 테스트하는 것이 좋습니다. 테스트를 포함하여이 프로젝트를 수행하는 유일한 사람은 아니지만 팀에서 일하는 유일한 사람은 아닙니다.
위에서 말한 것처럼, 내 질문은 개인 메소드에 대한 단위 테스트를 작성하는 것이 좋은 습관인지 여부에 관한 것이 아니라 피드백을 주셔서 감사합니다.
5
의심스러운 질문에 대한 의심스러운 제안이 있습니다. 릴리스 된 코드가 테스트에 대해 알아야하기 때문에 친구의 결합을 좋아하지 않습니다. 아래의 Nir의 대답은 그것을 완화하는 한 가지 방법이지만 여전히 테스트에 맞게 클래스를 변경하는 것을 좋아하지 않습니다. 상속을 자주 사용하지 않기 때문에 때로는 개인 메서드를 보호하고 테스트 클래스가 필요에 따라 상속 및 노출하도록합니다. 나는이 의견에 대해 적어도 세 가지 "부스 (boo hisses)"를 기대하지만, 실제로는 공개 API와 테스트 API가 다르고 여전히 개인 API와는 다를 수 있습니다. Meh.
—
J Trana
@JTrana : 적절한 답변으로 작성하지 않겠습니까?
—
Bart van Ingen Schenau
확인. 이것은 당신이 자랑스러워하는 사람들 중 하나가 아니지만 희망적으로 도움이 될 것입니다.
—
J Trana