개인 메서드의 단위 테스트

개인 메서드의 단위 테스트

---

이 질문에 이미 답변이 있습니다.

• 개인 함수 또는 개인 메서드, 필드 또는 내부 클래스가있는 클래스를 어떻게 테스트합니까? 50 개의 답변

일부 단위 테스트를 작성하는 중입니다. 특히 몇 가지 개인 방법을 테스트하고 싶습니다.

지금까지 사용하고 있습니다.

#define private public

그러나 단위 테스트의 관점에서 모든 캡슐화를 파괴 할 것이기 때문에 나는 이것에 만족하지 않습니다.

개인 메서드를 단위 테스트하는 데 어떤 메서드를 사용합니까?

---

메서드가 격리 된 상태에서 테스트 할 수있을만큼 복잡하다면 메서드를 자체 클래스로 리팩터링하고 공용 인터페이스를 통해 테스트합니다. 그런 다음 원래 클래스에서 개인적으로 사용하십시오.

---

#define질문에서 언급 한 불쾌한 해킹이 아니라 더 깨끗한 메커니즘은 테스트를 테스트중인 클래스의 친구로 만드는 것입니다. 이렇게하면 테스트 코드 (및 테스트 코드 만)가 비공개에 액세스 할 수 있으며 다른 모든 항목으로부터 보호됩니다.

그러나 공용 인터페이스를 통해 테스트하는 것이 좋습니다. 클래스 X에 개인 멤버 함수에 많은 코드가있는 경우 클래스 X 구현에 사용되는 새 클래스 Y를 추출하는 것이 좋습니다. 그런 다음이 새 클래스 Y를 공개 인터페이스를 통해 테스트 할 수 있습니다. 클래스 X의 클라이언트에 사용합니다.

---

Google Test를 사용하는 경우 FRIEND_TEST 를 사용 하여 테스트 픽스처를 테스트중인 클래스의 친구로 쉽게 선언 할 수 있습니다 .

그리고 다른 답변이 말한 것처럼 비공개 기능을 테스트하는 것이 명백히 나쁘다면 아마도 Google 테스트에 내장되지 않았을 것입니다.

이 답변에서 개인 기능 테스트가 좋거나 나쁠 때에 대해 자세히 읽을 수 있습니다 .

---

테스트 클래스를 원래 클래스의 친구로 만드십시오. 이 친구 선언은 #define UNIT_TEST깃발 안에있을 것 입니다.

class To_test_class {
   #ifdef UNIT_TEST
     friend test_class;
   #endif
}

이제 단위 테스트를 위해 flag를 사용하여 코드를 컴파일합니다 -DUNIT_TEST. 이렇게하면 개인 기능을 테스트 할 수 있습니다.

이제 UNIT_TEST플래그가 거짓 이므로 단위 테스트 코드가 프로덕션 환경으로 푸시되지 않습니다 . 따라서 코드는 여전히 안전합니다.

또한 단위 테스트를위한 특별한 라이브러리가 필요하지 않습니다.

---

나는 이것이 오래된 질문이라는 것을 알고 있지만 아무도 내가 선호하는 비교적 좋은 방법을 공유하지 않은 것 같으므로 여기에 있습니다.

당신이에서 테스트 할 방법 변경 private에를 protected. 다른 클래스의 경우 메서드는 계속 private되지만 이제 테스트하려는 개인 기능을 노출하는 기본 클래스에서 "테스트"클래스를 파생 할 수 있습니다.

다음은 최소한의 예입니다.

class BASE_CLASS {
  protected:
    int your_method(int a, int b);
};

class TEST_CLASS : public BASE_CLASS {
  public:
    int your_method(int a, int b) {
      return BASE_CLASS::your_method(a, b);
    }
}

물론 기본 클래스 대신 파생 클래스에서 테스트를 실행하려면 단위 테스트를 업데이트해야하지만 그 이후에는 기본 클래스에 대한 변경 사항이 "테스트"클래스에 자동으로 반영됩니다.

---

몇 시간이 지난 후 개인 기능을 테스트하려는 사람들에게 최고의 솔루션이되기로 결정했습니다. 이것은 Max DeLiso 와 Miloš 의 답변의 조합입니다 .

boost :: unit-test 를 사용 하는 경우 쉽고 우아한 솔루션이 있습니다.

1. 수업 protected대신 사용private

   /* MyClass.hpp */
   
   class MyClass {
   
   protected:
       int test() {
           return 1;
       }
   };
   

2. 조명기 만들기 :

   /* TestMyClass.cpp */
   
   class F : public MyClass {};
   
   
   BOOST_FIXTURE_TEST_SUITE(SomeTests, F)
   
   // use any protected methods inside your tests
   BOOST_AUTO_TEST_CASE(init_test)
   {
       BOOST_CHECK_EQUAL( test(), 1 );
   }
   BOOST_AUTO_TEST_SUITE_END()
   

이렇게 하면 클래스에 친구 를 추가하거나 추가 MyClass하지 않고도 모든 기능을 자유롭게 사용할 수 있습니다 !#define private public

---

정의 해킹은 끔찍한 아이디어입니다. 코드를 컴파일 할 때 전처리기로 임의로 다시 작성하는 것은 현명하지 않습니다.

Now as several people have mentioned already, it's debatable whether you should be testing private methods at all. But this doesn't cover the case where you've intentionally hidden constructors to restrict instantiaton to certain scopes, or a few other more esoteric cases.

Also, you can't friend a namespace and "friendship" is not inherited in C++ so depending on your unit testing framework you could be in trouble. Luckily, if you're using Boost.Test, there's in elegant solution to this issue in the form of Fixtures.

http://www.boost.org/doc/libs/1_52_0/libs/test/doc/html/utf/user-guide/fixture/per-test-case.html

You can friend the fixture and have it instantiate all of the instances that you use in your unit testing functions, declaring them as static to the fixture and with module scope. If you're using a namespace don't worry, you can just declare your fixture within the namespace and your test cases outside of the namespace, and then use the scope resolution operator to get to the static members.

The BOOST_FIXTURE_TEST_CASE macro will take care of instantiating and tearing down your fixture for you.

---

I don't think unit test cases would be required for private methods.

If a method is private it can used only within that class. If you have tested all the public methods using this private method then there is no need to test this separately since it was used only in those many ways.

참고URL : https://stackoverflow.com/questions/3676664/unit-testing-of-private-methods