왜 단위 테스트 개인 메소드가 나쁜 습관으로 간주됩니까?

문맥:

현재 Python에서 작은 프로젝트를 진행하고 있습니다. 나는 일반적으로 문서화되어 일부 공공 방법으로 내 수업을 구성하지만, 주로 높은 수준의 개념 (클래스의 사용자가 알고 사용해야하는지), 그리고 무리를 다루는 숨겨진 의 담당 방법 (밑줄로 시작하는) 복잡하거나 낮은 수준의 처리.

코드에 대한 자신감을 갖고 나중에 수정해도 이전 동작이 중단되지 않도록 테스트가 필수적이라는 것을 알고 있습니다.

문제:

신뢰할 수있는 기반에서 더 높은 수준의 공개 메소드를 빌드하기 위해 일반적으로 개인 메소드를 테스트합니다. 코드 수정으로 회귀가 발생했는지 여부와 위치를 쉽게 찾을 수 있습니다. 이는 내부 테스트가 약간의 수정으로 인해 중단 될 수 있으며 수정 / 교체해야 함을 의미합니다.

그러나 개인 테스트 단위 테스트는 적어도 논쟁의 여지가 있거나 더 자주 나쁜 관행으로 간주됩니다. 이유는 : 공개 행동 만 테스트해야합니다 ( 참조 )

질문:

모범 사례를 따르는 것에 관심이 있으며 이해하고 싶습니다.

• 개인 / 숨겨진 방법에서 단위 테스트를 사용하는 것이 왜 나쁜가 (위험은 무엇입니까)?
• 공개 방법이 저수준 및 / 또는 복잡한 처리를 사용할 수있는 모범 사례는 무엇입니까?

정밀성 :

• 질문 하는 방법 이 아닙니다 . 파이썬은 개인 정보 보호의 진정한 개념을 가지고 있지 않으며 숨겨진 메소드는 단순히 나열되지 않지만 이름을 알면 사용할 수 있습니다
• 나는 프로그래밍 규칙과 패턴을 배운 적이 없다 : 나의 마지막 수업은 80 년대부터 시작되었다. 나는 주로 시행 착오와 인터넷 참조를 통해 언어를 배웠다.

몇 가지 이유 :

1. 일반적으로 클래스의 전용 메서드를 테스트하려는 경우 디자인 냄새 (아이스버그 클래스, 재사용 가능한 공용 구성 요소가 충분하지 않은 등)입니다. 거의 항상 "더 큰"문제가 있습니다.

2. 공용 인터페이스를 통해 테스트 할 수 있습니다 (클라이언트가 호출 / 사용하는 방식이기 때문에 테스트하려는 방법). 개인 메소드에 대한 모든 통과 테스트에서 녹색 표시등을 보면 잘못된 보안 감각을 얻을 수 있습니다. 공용 인터페이스를 통해 개인 기능에 대한 최첨단 사례를 테스트하는 것이 훨씬 좋습니다.

3. 개인 방법을 테스트하면 심각한 테스트 복제 (유사하게 보이는 느낌)가 발생할 위험이 있습니다. 필요한 것보다 많은 테스트가 중단 될 수 있기 때문에 요구 사항이 변경 될 때 중요한 결과가 발생합니다. 또한 테스트 스위트로 인해 리팩토링하기 어려운 위치에 놓을 수 있습니다. 테스트 스위트는 안전하게 재 설계하고 리팩토링 할 수 있도록 도와주기 때문에 가장 아이러니합니다.

여전히 개인 부품을 시험하고 싶은 유혹이 있다면 팁 (귀하와 YMMV를 귀찮게하는 경우 사용하지 마십시오.하지만 과거에는 나에게 잘 작동했습니다) : 때로는 개인 기능에 대한 단위 테스트를 작성하여 확인하십시오. 그들은 그들이 당신이 가치 있다고 생각하는 방식을 정확하게 작동하고 있습니다 (특히 언어를 처음 사용하는 경우). 그러나 테스트가 완료된 후에는 테스트를 삭제하고, 공개 테스트가 확실하고 누군가 개인 기능을 심각하게 변경 한 경우 포착 할 수 있도록하십시오.

개인 메소드를 테스트 할시기 : 이 답변이 인기를 얻었으므로 "모범 사례"는 항상 "최고 사례"라고 언급 할 의무가 있습니다. 맹목적으로 또는 맹목적으로해야한다는 의미는 아닙니다. 개인용 메소드를 테스트해야한다고 생각하고 (레거시 애플리케이션에 대한 특성화 테스트를 작성하는 것과 같은) 정당한 이유가있는 경우 개인용 메소드를 테스트하십시오 . 특정 상황은 항상 일반적인 규칙이나 모범 사례보다 우선합니다. 잘못 될 수있는 몇 가지 사항 만 알아 두십시오 (위 참조).

나는 이것을 반복하지 않을 SO에 대해 자세히 설명하는 대답이 있습니다 : https : //.com/questions/105007/should-i-test-private-methods-or-only-public-ones/ 47401015 # 47401015

단위 테스트의 주요 목적 중 하나는 프로그램 내부를 리팩터링하고 기능이 손상되지 않았 음을 확인할 수 있다는 것입니다. 프로그램 코드를 변경하면 테스트를 다시 작성해야합니다.

개인 메소드에 대한 단위 테스트 작성 은 단위 테스트를 구현 세부 사항에 연결합니다.

단위 테스트는 클래스의 외부 표면 (공개 API)에서 클래스의 동작을 테스트해야합니다. 단위 테스트는 클래스의 내부에 대해 아무것도 알 필요가 없습니다. 클래스의 구현 세부 사항에 대해 단위 테스트를 작성하면 리팩토링 할 때가 필요합니다. 리팩토링은 안정적인 API의 일부가 아니기 때문에 테스트를 거의 중단 할 것입니다.

말했다, 왜 수 당신은 당신의 개인 방법에 대한 단위 테스트를 작성하려면?

단위 테스트와 점진적인 개발 사이에는 자연스러운 긴장이 있습니다. REPL (read-eval-print loop)을 사용하는 소프트웨어 개발자는 클래스 나 함수를 "성장"할 때 작은 기능을 신속하게 작성하고 테스트하는 것이 얼마나 생산적인지 입증 할 수 있습니다. 단위 테스트 중심 환경에서이를 수행하는 유일한 방법은 개인용 메소드에 대한 단위 테스트를 작성하는 것이지만 그렇게하는 데 많은 어려움이 있습니다. 단위 테스트는 작성하는 데 시간이 걸리고 테스트 할 실제 방법이 필요하며 테스트 프레임 워크는 외부 API를 오염시키지 않도록 메소드를 비공개로 유지하는 기능을 지원해야합니다.

C # 및 .NET과 같은 일부 에코 시스템에는 REPL과 같은 환경 (Linqpad와 같은 도구)이 작성 될 수있는 방법이 있지만 프로젝트에 액세스 할 수 없으므로 유틸리티가 제한됩니다. Visual Studio의 즉각적인 창은 불편합니다. 여전히 완전한 Intellisense가 없으며 완전한 이름을 사용해야하며 사용할 때마다 빌드를 트리거합니다.

내 경험에 따르면 내부 클래스, 단위 테스트를 수행하는 단위는 일반적으로 테스트 된 함수, 클래스를 가져와야 함을 의미합니다. 다른 수준의 추상화를 만듭니다.

이는 단일 책임 원칙을보다 잘 준수하도록합니다.

나는 이것이 커버리지 테스트에 일반적인 문제를 노출시키기 때문에 좋은 질문이라고 생각합니다. 하지만 좋은 대답은 이론적으로, 당신이해야하기 때문에 문제가 정확히 잘 아니라고 말할해야 하지 단위 테스트 할 수있을 개인 방법. 그것이 그들이 사적인 이유 입니다.

아마도 더 좋은 질문은 "개인 메소드를 테스트하고 싶을 때 어떻게해야합니까?"입니다.답은 분명합니다. 테스트 할 수있는 방식으로 노출해야합니다. 이제 이것이 반드시 메소드를 공개해야한다는 것을 의미하지는 않습니다. 아마도 더 높은 추상화를 원할 것입니다. 다른 라이브러리 또는 API로 이동하면 기본 API에서 해당 기능을 노출하지 않고도 해당 라이브러리에서 테스트를 수행 할 수 있습니다.

메서드의 접근성 수준이 다른 이유가 있으므로 항상 클래스가 어떻게 사용되는지 생각해야합니다.