친구 클래스 사용 대 C ++에서 단위 테스트를 위해 액세서 추가?

Question

테스트 클래스 A 친구를 만드는 것과는 반대로 단위 테스트를 위해 객체의 내부 상태를 반환하는 기능을 추가하는 것이 낫습니까? - 특히 단위 테스트의 경우를 제외하고 기능에 사용되지 않는 경우.

Answer 1

단위 테스트는 시간의 95%가 공개적으로 노출 된 클래스 표면을 테스트해야합니다. 표지 아래에서 무언가를 테스트하는 경우 구현 세부 사항을 테스트하는 것입니다. 구현을 쉽게 변경하고 여전히 테스트가 작동 할 수 있기 때문에 본질적으로 깨지기 쉬운 것입니다. 깨지기 쉬울뿐만 아니라 계획된 사용 시나리오에서 실제로 불가능한 것을 테스트하는 데 유혹을받을 수도 있습니다.이 시나리오는 시간 낭비입니다.

추가하려는 액세서의 요점이 함수가 원하는 효과가 있는지 여부를 테스트하는 것이라면, 클래스 디자인은 다른 원칙을 위반할 수 있습니다. 즉, 상태 대기업과 같은 클래스는 항상 그 상태를 명확하게해야합니다. 사람들이 수업과 상호 작용할 때 발생하는 일에 영향을 미칩니다. 이 경우 읽기 전용 액세서를 제공하는 것이 옳습니다. 클래스의 동작에 영향을 미치지 않으면 구현 세부 사항에 대해 이전 비트를 참조하십시오.

그리고 당신이 올바르게 말했듯이, 사용되지 않은 물건을 가진 클래스의 공공 표면을 혼란스럽게하는 것도 그 이유 때문에 바람직하지 않습니다.

만약 내가 가졌다 귀하의 경우에는 액세스터와 친구를 선택하기 위해서는 친구를 선택할 것입니다. 너 테스트를 소유하고 꼬집음으로 변경할 수 있습니다. 당신은 추가 액세서를 사용할 수있는 방법을 찾는 광대의 코드를 소유하지 않을 수 있습니다.

Answer 2

허용 된 답변에 동의하지 않고 대신 친구 수업의 사용을 추천합니다.

테스트중인 상태의 일부는 아마도 클래스의 구현에만 해당됩니다. 다른 코드가 정상적으로 알지 못하거나 신경 쓰지 않고 의존해서는 안되는 세부 사항을 테스트하고 있습니다. 공개 액세서 기능은 이러한 구현 세부 사항을 클래스 인터페이스의 일부로 만듭니다. 테스트중인 내부 상태가 의도 된 인터페이스의 일부가 아닌 경우 공개 기능을 통해 보이지 않아야합니다. 순수한 관점에서 친구 수업은 기술적으로 공개 인터페이스의 일부이기 때문에 두 개의 잘못된 답변 사이에 갇혀 있습니다. 제 생각에는 문제가 발생합니다. 어떤 옵션이 도로에서 코딩 선택이 좋지 않을 가능성이 적습니까? 일련의 구현 의존적 공개 액세서 기능을 사용하면 클래스의 구현 의존적 개념 모델을 부주의하게 장려하여 클래스의 구현 의존적 사용으로 이어질 것입니다. 적절하게 지명되고 문서화 된 단일 친구 수업은 남용 될 가능성이 적습니다.

일반적으로 나는 멤버 변수에 대한 직접 액세스보다 액세스 기능을 선호하는 권장 사항에 강력하게 동의하지만,이 모범 사례는 구현 의존적 내부 상태의 단위 테스트에 적용된다는 데 동의하지 않습니다. 합리적인 중간지면은 사용하는 것입니다 사적인 접근 자 기능은 유닛 테스트가 신경 쓰고 단위 테스트에서 액세서 기능을 사용할 수있을 정도로 훈련을받습니다. 내 의견.

Answer 3

단위 테스트에 친구 수업을 사용하는 것은 완벽하게 합법적이며 캡슐화를 유지할 수 있습니다. 클래스를보다 테스트하기 위해 클래스 공개 인터페이스를 수정해서는 안됩니다. 이런 식으로 생각하십시오. 제 3 자 FTP 라이브러리를 구입하고 그것을 사용하려고하고 공개 인터페이스라면 단순히 단위 테스트로 인해 알 필요조차없는 많은 방법으로 어수선한 경우! 단위 테스트를 보상하기 위해 보호 된 인터페이스를 수정하는 것도 나쁘다. 내가 어떤 수업에서 물려 받고 있다면, 나는 어떤 방법이 나에게 유용한 지, 단위 테스트로 인해 어떤 방법이 거기에 있는지 걱정할 필요가 없습니다 !!! 단위 테스트에 친구 수업을 사용하면 단순하고 쉽게 사용하기 쉬운 클래스 인터페이스를 유지할 수 있습니다. 그것은 캡슐화와 추상화를 보존하는 데 도움이됩니다 !!!

테스트중인 클래스가 테스트 클래스와 "엄격하게 결합"되어서는 안되며 테스트 클래스에 대해 "알지 못해서"테스트 클래스를 "엄격하게 결합"해서는 안되기 때문에 단위 테스트를 위해 친구 클래스를 사용하는 것이 나쁘다는 주장을 들었습니다. 나는 이것을 사지 않는다. 클래스 상단에 추가 된 한 줄입니다.

친구 클래스 MyClasstest;

그리고 이제 원하는 방식으로 수업을 테스트 할 수 있습니다!

이제 나는 당신이 필요하지 않은 경우 친구 수업을 사용해서는 안된다는 데 동의합니다. 친구를 만들지 않고 테스트가 필요한 것을 테스트 할 수 있다면, 반드시 그렇습니다. 그러나 인생이 어려워지고 친구 수업을 사용하면 인생이 다시 쉬워지면 사용하십시오!

Answer 4

공개 회원이나 친구 수업을 통해 액세스를 허용하지 않고 액세서를 사용하는 것이 좋습니다.

나는 친구 수업을 사용하는 것이 실제로 당신에게 어떤 혜택을 얻는다고 생각하지 않으며, 그것은 당신의 삶을 훨씬 더 악화시킬 수있는 잠재력을 가지고 있습니다. 코드가 오랫동안 머무를 경우 예상하지 못하는 방식으로 사용될 가능성이 높습니다. 액세스 기능은 지금 테스트에만 사용될 수 있지만 앞으로 어떤 일이 일어날 지 누가 알 수 있습니까? 변수에 직접 액세스하는 대신 액세서를 사용하면 훨씬 더 유연성이 높아지고 비용이 많이들 수 있습니다.

다른 주장은 공개 회원보다는 액세서를 사용하는 것이 좋은 습관이라는 것입니다. 좋은 습관을 개발하는 것은 프로그래머로서 중요한 기술입니다.

Answer 5

내부 상태를 "보호"하는 것은 어떻습니까? 그런 다음 파생 클래스를 사용하여 UnitTest를 수행하십시오.

Answer 6

나는이를 이해하는 것이 합리적이라면 액세서를 사용자에게 제공함으로써 미래를 방지하고 테스트 가능성을 향상 시켜서 수업을 방지하는 것 사이에 차이가 있어야한다고 생각합니다. 나는 또한 테스트의 목적으로 유일한 목적을 위해 수업을받는 큰 팬이 아닙니다. 이것은 내가 그것을 갖지 않는 것을 선호하는 곳에서 단단한 커플 링을 소개하기 때문입니다.

액세서의 유일한 사용이 테스트 사례가 클래스의 내부 상태를 확인할 수있는 방법을 제공하는 경우 일반적으로 공개적으로 노출하는 것은 의미가 없습니다. 또한 나중에 변경하려는 구현 세부 사항을 묶을 수 있지만 다른 사람이 해당 액세서를 사용하고 있기 때문에 할 수 없습니다.

이를 위해 내가 선호하는 솔루션은 제공하는 것입니다 보호 액세서는 클래스 사용자에게 공개 인터페이스의 일부가 아니라는 것을 명확하게 전달할 수 있습니다. 그런 다음 테스트는 부모의 기능에 대한 콜 스루 스터브를 포함하는 최소한의 파생 된 클래스를 생성하지만 액세서리가 공개적으로 공개하여 테스트 사례에서 사용할 수 있도록합니다.