일반적인 C ++ 코드는 다음과 같습니다.
foo.hpp
#pragma once
class Foo {
public:
void f();
void g();
...
};foo.cpp
#include "foo.hpp"
namespace {
const int kUpperX = 111;
const int kAlternativeX = 222;
bool match(int x) {
return x < kUpperX || x == kAlternativeX;
}
} // namespace
void Foo::f() {
...
if (match(x)) return;
...그것은 적절한 관용적 C ++ 코드처럼 보입니다-클래스, 그 도우미 함수에 match의해 사용되는 도우미 함수 Foo, 그 도우미 함수에 대한 상수.
그런 다음 테스트를 작성하고 싶습니다.
에 대한 별도의 단위 테스트를 작성하는 것이 완벽하게 논리적입니다 match. 왜냐하면 사소한 것이 아니기 때문입니다.
그러나 익명 네임 스페이스에 있습니다.
물론을 호출하는 테스트를 작성할 수 있습니다 Foo::f(). 그러나 Foo무겁고 복잡한 경우 좋은 시험이되지 않을 것입니다. 이러한 시험은 피검사자를 다른 관련없는 요소와 격리시키지 않습니다.
따라서 match익명 네임 스페이스에서 다른 모든 것을 옮겨야 합니다.
질문 : 함수와 상수를 테스트에서 사용할 수 없게 만드는 익명 네임 스페이스에 넣는 점은 무엇입니까?
명명되지 않은 네임 스페이스에서 C ++ 코드를 테스트 하는 단위에 대한 몇 가지 아이디어 가 있습니다. 결국 그것은 개인 멤버 함수와 동일한 문제입니다 : 그것들은 방해하지 않고 테스트 할 수는 없지만 단위 테스트를 위해 정보 숨기기를 포기하고 싶지 않습니다 (예 : stackoverflow.com/a/3676680/3235496 ).
—
manlio
개인의 방법을 테스트하거나 테스트하지 않는 경우와 개념이 크게 다르지 않습니다. 따라서 프로그래머에서 "unit test private"을 검색하면 사례에 직접 적용 할 수있는 많은 답변을 얻을 수 있습니다.
—
Doc Brown
@DocBrown 나는 함수를 테스트하는 방법을 묻지 않았다. 네임 스페이스. "왜 anon. 네임 스페이스에 코드를 넣을까요?" (질문 끝에있는 텍스트 참조). 제목을 다른 것으로 변경 한 것에 대한 Blame Ixrec.
—
Abyx
@Abyx : 위에서 언급 한 다른 답변에서 개인 방법을 테스트하는 것은 좋지 않은 아이디어
—
Doc Brown
friend이며 해당 목적을 위해 키워드를 남용하는 것은 권장되지 않는다는 많은 전문가들의 큰 합의를 찾을 수 있습니다. 메소드에 대한 제한으로 인해 더 이상 직접 테스트 할 수없는 상황이 발생하면 개인 메소드가 유용하지 않은 것입니다.
foo.cpp헤더가 아니라에 있습니다! OP는 헤더에 네임 스페이스를 넣지 말아야한다는 것을 잘 이해하는 것 같습니다.