TDD를 수행 할 때 개인용 메소드를 피해야합니까?

지금 막 TDD를 배우고 있습니다. 개인 API는 테스트 할 수 없으며 공개 API가 객체의 무결성을 확인하기에 충분한 정보를 제공하기 때문에 걱정할 필요가 없다는 것을 이해합니다.

한동안 OOP를 이해했습니다. 개인 메소드가 객체를보다 캡슐화하여 변경 및 오류에 더 강하게 만든다는 것을 이해합니다. 따라서 기본적으로 사용되어야하며 클라이언트에게 중요한 방법 만 공개해야합니다.

글쎄, 개인 메서드 만 가지고 있고 이벤트를 수신하여 다른 객체와 상호 작용하는 객체를 만들 수 있습니다. 이것은 매우 캡슐화되어 있지만 완전히 테스트 할 수는 없습니다.

또한 테스트를 위해 메소드를 추가하는 것은 나쁜 습관으로 간주됩니다.

이것은 TDD가 캡슐화와 충돌한다는 것을 의미합니까? 적절한 균형은 무엇입니까? 나는 지금 내 방법의 대부분 또는 전부를 공개하려는 경향이 있습니다 ...

구현에 대한 테스트보다 인터페이스에 대한 테스트를 선호하십시오.

개인적인 방법은 테스트 할 수 없다는 것을 이해합니다.

이는 개발 환경에 따라 다릅니다 (아래 참조).

공개 API는 객체의 무결성을 검증하기위한 충분한 정보를 제공하므로 [비공개 메소드]에 대해 걱정할 필요가 없습니다.

맞습니다. TDD는 인터페이스 테스트에 중점을 둡니다.

전용 메소드는 리팩터링주기 동안 변경 될 수있는 구현 세부 사항입니다. 인터페이스 나 블랙 박스 동작 을 변경하지 않고 리팩터링 할 수 있어야합니다 . 실제로 이는 TDD의 이점 중 하나입니다. 클래스 내부의 변경 사항이 해당 클래스의 사용자에게 영향을 미치지 않는다는 확신을 쉽게 생성 할 수 있습니다.

글쎄, 개인 메서드 만 가지고 있고 이벤트를 수신하여 다른 객체와 상호 작용하는 객체를 만들 수 있습니다. 이것은 매우 캡슐화되어 있지만 완전히 테스트 할 수는 없습니다.

클래스에 퍼블릭 메소드가없는 경우에도 이벤트 핸들러는 퍼블릭 인터페이스 이며 테스트 할 수 있는 퍼블릭 인터페이스 에 대한 이벤트 핸들러 입니다.

이벤트는 인터페이스이므로 해당 개체를 테스트하기 위해 생성해야하는 이벤트입니다.

모의 객체 를 테스트 시스템 의 접착제 로 사용하는 방법을 살펴보십시오 . 이벤트를 생성하고 결과 상태 변경 (다른 수신자 모의 오브젝트에 의해 가능함)을 선택하는 단순 모의 오브젝트를 작성할 수 있어야합니다.

또한 테스트를 위해 메소드를 추가하는 것은 나쁜 습관으로 간주됩니다.

절대적으로 내부 상태를 노출시키는 것에 매우주의 해야합니다 .

이것은 TDD가 캡슐화와 충돌한다는 것을 의미합니까? 적절한 균형은 무엇입니까?

절대적으로하지.

TDD는 클래스를 단순화하는 것 이외의 클래스 구현을 변경해서는 안됩니다 ( 이전 시점에서 YAGNI 를 적용하여 ).

TDD를 사용하는 모범 사례는 TDD를 사용하지 않는 모범 사례와 동일합니다. 개발하는 동안 인터페이스를 사용하고 있기 때문에 더 빠른 이유를 찾을 수 있습니다.

나는 지금 내 방법의 대부분 또는 전부를 공개하려는 경향이 있습니다 ...

이것은 오히려 목욕물로 아기를 버리는 것입니다.

당신은 안 필요 당신이 TDD 방식으로 개발할 수 있도록 모든 방법을 공개 할 수 있습니다. 개인 방법이 실제로 테스트 할 수 없는지 확인하려면 아래 내 노트를 참조하십시오.

개인 메소드 테스트에 대한 자세한 설명

언어 / 환경에 따라 수업의 일부 개인 행동 을 절대적으로 단위 테스트 해야하는 경우 세 가지 옵션이 있습니다.

1. 시험을 치르려는 수업에 시험을 치십시오.
2. 테스트를 다른 클래스 / 소스 파일에 넣고 테스트하려는 개인 메소드를 공개 메소드로 노출하십시오.
3. 테스트 코드와 프로덕션 코드를 별도로 유지하면서 테스트 코드가 프로덕션 코드의 개인 메소드에 액세스 할 수있는 테스트 환경을 사용하십시오.

분명히 세 번째 옵션이 가장 좋습니다.

1) 시험을 치르려는 수업에 시험을 넣으십시오 (이상적이지 않음)

테스트중인 프로덕션 코드와 동일한 클래스 / 소스 파일에 테스트 케이스를 저장하는 것이 가장 간단한 옵션입니다. 그러나 전 처리기 지시문이나 주석이 많지 않으면 테스트 코드로 인해 생산 코드가 불필요하게 부풀려지고 코드를 구성한 방법에 따라 실수로 해당 코드의 사용자에게 내부 구현이 노출 될 수 있습니다.

2) 테스트하려는 개인 메소드를 공개 메소드로 노출하십시오 (실제로 좋은 생각은 아닙니다)

제안 된 바와 같이, 이것은 매우 나쁜 관행이며, 캡슐화를 파괴하며 내부 구현을 코드 사용자에게 노출시킵니다 .

3) 더 나은 테스트 환경을 사용하십시오 (사용 가능한 경우 최상의 옵션)

Eclipse 세계에서는 fragments 를 사용하여 3.를 달성 할 수 있습니다 . C # 세계에서는 부분 클래스를 사용할 수 있습니다 . 다른 언어 / 환경은 종종 비슷한 기능을 가지고 있으므로 찾기 만하면됩니다.

맹목적으로 1. 또는 2.가 유일한 옵션이라고 가정하면 테스트 코드로 불완전한 프로덕션 소프트웨어 또는 더러운 리넨을 공공 장소에서 씻을 수있는 불쾌한 클래스 인터페이스가 발생할 수 있습니다. * 8 ')

• 대체로 개인 구현에 대해 테스트하지 않는 것이 훨씬 좋습니다.

물론 개인 메소드를 가질 수 있으며 물론 테스트 할 수도 있습니다.

어느 쪽이 어떤 당신이 그런 식으로 테스트 할 수있는 경우에 실행하는 개인 방법을 얻을 수있는 방법, 또는이없는 어떤 실행하는 개인 얻을 수있는 방법은 어떤 경우에 왜 도대체 당신은 단지 그것을 테스트하기 위해 노력하고있다 망할 것을 삭제하십시오!

귀하의 예에서 :

글쎄, 개인 메서드 만 가지고 있고 이벤트를 수신하여 다른 객체와 상호 작용하는 객체를 만들 수 있습니다. 이것은 매우 캡슐화되어 있지만 완전히 테스트 할 수는 없습니다.

왜 테스트 할 수 없습니까? 이벤트에 대한 반응으로 메소드가 호출되면 테스트가 오브젝트에 적절한 이벤트를 제공하도록하십시오.

그것은 개인적인 방법이 없다는 것이 아니라 캡슐화를 깨뜨리지 않는 것입니다. 개인 메소드를 가질 수 있지만 공개 API를 통해 테스트해야합니다. 공개 API가 이벤트를 기반으로하는 경우 이벤트를 사용하십시오.

보다 일반적인 개인 헬퍼 메소드의 경우이를 호출하는 공용 메소드를 통해 테스트 할 수 있습니다. 특히, 실패한 테스트를 통과하기위한 코드 작성 만 허용되고 테스트는 공개 API를 테스트하기 때문에 작성하는 모든 새 코드는 일반적으로 공개됩니다. 전용 메소드 는 기존의 공개 메소드 에서 추출 된 경우 추출 메소드 리팩토링 결과로만 나타납니다 . 그러나이 경우 공개 메소드를 테스트하는 원래 테스트는 여전히 공개 메소드가 비공개 메소드를 호출하므로 비공개 메소드도 포함합니다.

따라서 일반적으로 개인용 메소드는 이미 테스트 된 공개 메소드에서 추출되어 이미 테스트 된 경우에만 나타납니다.

코드에서 새 클래스를 만들 때 몇 가지 요구 사항에 응답하기 위해 수행합니다. 요구 사항은 말을 어떤 코드가 수행해야하지 하는 방법 . 따라서 대부분의 테스트가 공개 방법 수준에서 발생하는 이유를 쉽게 이해할 수 있습니다.

테스트를 통해 코드가 예상대로 작동하는지, 예상 할 때 적절한 예외가 발생 하는지 등을 검증합니다. 실제로 개발자가 코드를 구현하는 방식은 중요하지 않습니다. 구현, 즉 코드의 기능에 대해서는 신경 쓰지 않지만 개인 메서드 테스트는 피하는 것이 좋습니다.

공개 메소드가없고 이벤트를 통해서만 외부 세계와 상호 작용하는 클래스를 테스트하는 경우 테스트를 통해 이벤트를 보내고 응답을 청취하여이를 테스트 할 수도 있습니다. 예를 들어, 클래스가 이벤트를 수신 할 때마다 로그 파일을 저장해야하는 경우 단위 테스트는 이벤트를 전송하고 로그 파일이 작성되었는지 확인합니다.

마지막으로, 어떤 경우에는 개인 메소드를 테스트하는 것이 완벽하게 유효합니다. 따라서 .NET에서 솔루션이 공용 메소드만큼 간단하지 않더라도 공용 클래스뿐만 아니라 개인 클래스도 테스트 할 수 있습니다.

개인적인 방법은 테스트 할 수 없다는 것을 이해합니다.

나는 그 진술에 동의하지 않거나, 당신은 개인 메소드를 직접 테스트하지 않는다고 말할 것 입니다. 공개 메소드는 다른 개인 메소드를 호출 할 수 있습니다. 어쩌면 저자는 "작은"메소드를 원했고 코드 중 일부를 영리하게 명명 된 개인 메소드로 추출했습니다.

공개 메소드 작성 방법에 관계없이 테스트 코드는 모든 경로를 포함해야합니다. 테스트 후 하나의 개인 메소드에서 분기 명령문 중 하나 (if / switch)가 테스트에서 다루어지지 않았다는 것을 발견하면 문제가있는 것입니다. 사례를 놓치고 구현이 정확하거나 구현이 잘못되어 해당 지점이 실제로 존재해서는 안됩니다.

그렇기 때문에 공용 메소드 테스트에도 개인 메소드가 포함되도록 Cobertura와 NCover를 많이 사용합니다. 개인적인 방법으로 좋은 OO 객체를 작성하고 TDD / Testing을 방해하지 마십시오.

CUT가 상호 작용하는 인스턴스를 제공하기 위해 Dependency Injection을 사용하는 한 예제는 여전히 완벽하게 테스트 할 수 있습니다. 그런 다음 모의를 사용하여 관심있는 이벤트를 생성 한 다음 CUT가 해당 종속성에 대한 올바른 조치를 수행하는지 여부를 관찰 할 수 있습니다.

반면, 이벤트 지원이 좋은 언어를 사용하는 경우 약간 다른 경로를 이용할 수 있습니다. 객체가 이벤트 자체를 구독하는 것을 좋아하지 않고 대신 객체를 만드는 팩토리가 객체의 공용 메소드에 이벤트를 연결합니다. 테스트가 더 쉽고, CUT를 테스트해야하는 이벤트 종류를 외부에서 볼 수 있습니다.

개인 방법을 사용하여 포기할 필요는 없습니다. 그것들을 사용하는 것이 합리적이지만 테스트 관점에서 캡슐화를 깨거나 클래스에 테스트 특정 코드를 추가하지 않고 직접 테스트하기가 더 어렵습니다. 비결은 코드를 더럽힌 것처럼 느끼기 때문에 장내를 분출하게 만드는 것을 최소화하는 것입니다.

이것들은 실행 가능한 균형을 시도하고 달성하기 위해 명심해야 할 것들입니다.

1. 사용하는 개인 메소드 및 특성 수를 최소화하십시오. 수업에 필요한 대부분의 자료는 어쨌든 공개적으로 노출되어야하는 경향이 있으므로, 그 영리한 방법을 비공개로 만들어야하는지 생각해보십시오.
2. 개인 메소드에서 코드의 양을 최소화하십시오-실제로이 작업을 수행해야합니다-다른 메소드의 동작을 통해 간접적으로 테스트하십시오. 100 % 테스트 적용 범위를 기대할 수 없으며 디버거를 통해 몇 가지 값을 직접 확인해야합니다. 개인 메소드를 사용하여 예외를 쉽게 간접적으로 테스트 할 수 있습니다. 개인 속성은 수동으로 또는 다른 방법으로 테스트해야 할 수도 있습니다.
3. 간접 또는 수동 검사가 잘 이루어지지 않으면 보호 된 이벤트를 추가하고 인터페이스를 통해 액세스하여 개인 정보를 노출하십시오. 이렇게하면 캡슐화 규칙이 효과적으로 "구부러 지지만"실제로 테스트를 실행하는 코드를 제공 할 필요가 없습니다. 단점은 필요한 경우 이벤트가 시작되도록하기 위해 약간의 추가 내부 코드가 생성 될 수 있다는 것입니다.
4. 퍼블릭 메소드가 충분히 "안전하지 않다"고 생각되면, 메소드에서 사용 방법을 제한하기 위해 일종의 유효성 검증 프로세스를 구현할 수있는 방법이 있는지 확인하십시오. 메소드를 구현하는 더 좋은 방법을 생각하거나 다른 클래스가 형성되기 시작하는 것을 통해 이것을 생각할 수 있습니다.
5. 공용 메소드에 대해 "소설"을 수행하는 많은 개인 메소드가있는 경우 새 클래스가 추출 대기 중일 수 있습니다. 이 클래스를 별도의 클래스로 직접 테스트 할 수 있지만 클래스를 사용하는 클래스 내에서 비공개로 구현할 수 있습니다.

측면으로 생각하십시오. 수업을 작게 유지하고 방법을 작게 유지하고 많은 구성을 사용하십시오. 더 많은 작업처럼 들리지만 결국에는 더 개별적으로 테스트 가능한 항목으로 끝나고 테스트가 더 간단 해지며 실제, 크고 복잡한 객체 대신 간단한 모형을 사용할 수있는 더 많은 옵션이 있습니다. 팩터링되고 느슨하게 결합 된 코드, 더 중요한 것은 더 많은 옵션을 제공한다는 것입니다. 작게 유지하면 결국 각 시간에 개별적으로 확인해야하는 항목의 수가 줄어들 기 때문에 시간이 절약되는 경향이 있으며, 수업이 커질 때 발생할 수있는 코드 스파게티를 자연스럽게 줄이는 경향이 있습니다. 내부적으로 상호 의존적 인 코드 동작.

글쎄, 개인 메서드 만 가지고 있고 이벤트를 수신하여 다른 객체와 상호 작용하는 객체를 만들 수 있습니다. 이것은 매우 캡슐화되어 있지만 완전히 테스트 할 수는 없습니다.

이 개체는 이러한 이벤트에 어떻게 반응합니까? 아마도 다른 객체에서 메소드를 호출해야 할 것입니다. 해당 메소드가 호출되는지 확인하여 테스트 할 수 있습니다. 모의 객체를 호출하면 예상대로 수행한다고 쉽게 주장 할 수 있습니다.

문제는 객체의 다른 객체와의 상호 작용 만 테스트한다는 것입니다. 우리는 물체 안에서 무슨 일이 일어나고 있는지 상관하지 않습니다. 따라서 더 이상 공개 방법이 없어야합니다.

나는이 같은 문제로 어려움을 겪었습니다. 실제로, 그 문제를 해결하는 방법은 다음과 같습니다. 나머지 프로그램이 해당 클래스와 인터페이스하는 것을 어떻게 기대하십니까? 이에 따라 수업을 테스트하십시오. 이렇게하면 나머지 프로그램이 어떻게 인터페이스하는지에 따라 수업을 디자인해야하며 실제로 수업의 캡슐화와 좋은 디자인을 장려해야합니다.

개인용 기본 수정 자 대신. 그런 다음 공개 메소드와 결합되지 않고 해당 메소드를 개별적으로 테스트 할 수 있습니다. 이를 위해서는 테스트가 기본 코드와 동일한 패키지 구조를 가져야합니다.

몇 가지 개인적인 방법은 일반적으로 문제가되지 않습니다. 코드가 퍼블릭 메서드에 인라인 된 것처럼 퍼블릭 API를 통해 테스트합니다. 개인 방법을 과도 하게 사용하면 응집력이 떨어질 수 있습니다. 수업은 하나의 응집력을 지녀야하며, 사람들은 실제로는 존재하지 않는 곳에서 응집력을 보이기 위해 사적인 방법을 만듭니다.

예를 들어, 해당 이벤트에 대한 응답으로 많은 데이터베이스 호출을 작성하는 이벤트 핸들러가있을 수 있습니다. 데이터베이스 핸들러를 작성하기 위해 이벤트 핸들러를 인스턴스화하는 것은 명백히 나쁜 습관이므로, 모든 데이터베이스 관련 호출을 실제로 별도의 클래스로 가져와야 할 경우 모든 데이터베이스 관련 호출을 전용 메소드로 만드는 유혹이 있습니다.

이것은 TDD가 캡슐화와 충돌한다는 것을 의미합니까? 적절한 균형은 무엇입니까? 나는 지금 내 방법의 대부분 또는 전부를 공개하려고한다.

TDD는 캡슐화와 충돌하지 않습니다. 선택한 언어에 따라 getter 메소드 또는 특성의 가장 간단한 예를 들어보십시오. 고객 객체가 있고 ID 필드를 원한다고 가정 해 봅시다. 제가 작성할 첫 번째 테스트는 "customer_id_initializes_to_zero"와 같은 테스트입니다. 구현되지 않은 예외를 발생시키고 테스트 실패를 감시하도록 getter를 정의합니다. 그런 다음 테스트 통과를 위해 할 수있는 가장 간단한 방법은 게터가 0을 반환하는 것입니다.

거기에서 나는 다른 테스트, 아마도 고객 ID가 실제적이고 기능적인 필드 인 테스트 일 것이다. 어떤 시점에서, 아마도 고객 클래스가 getter에 의해 리턴되는 것을 추적하기 위해 사용하는 개인 필드를 작성해야 할 것입니다. 정확히 어떻게 추적합니까? 간단한 백업 int입니까? 문자열을 추적 한 다음 int로 변환합니까? 20 개의 정수를 추적하고 평균을 내립니까? 외부 세계는 신경 쓰지 않으며 TDD 테스트는 신경 쓰지 않습니다. 그것은 캡슐화 된 세부 사항입니다.

TDD를 시작할 때 이것이 항상 명백한 것은 아니라고 생각합니다. 내부에서 수행하는 메소드를 테스트하는 것이 아니라 클래스의 세부적인 문제를 테스트하는 것입니다. 따라서 메소드 DoSomethingToFoo()가 Bar를 인스턴스화하고, 메소드를 호출하고, 특성 중 하나에 2를 추가하는 등의 테스트는하지 않습니다. 오브젝트의 상태를 변경 한 후 일부 상태 접근자가 변경되었는지 테스트하고 있습니다. (아니요). 그것은 당신의 테스트의 일반적인 패턴입니다 : "테스트중인 클래스에 X를 할 때, Y를 관찰 할 수 있습니다". 그것이 Y에 도달하는 방법은 테스트의 관심사가 아니며, 이것이 캡슐화 된 것이며 TDD가 캡슐화와 충돌하지 않는 이유입니다.

사용하지 마십시오? 아니요.로 시작
하지 마십시오 ? 예.

TDD를 사용하여 추상 클래스를 사용할 수 있는지 묻지 않았습니다. TDD 중에 추상 클래스가 나타나는 방식을 이해하는 경우 동일한 원칙이 개인용 메소드에도 적용됩니다.

개인 메서드를 직접 테스트 할 수없는 것처럼 추상 클래스에서 메서드를 직접 테스트 할 수는 없지만 추상 클래스와 개인 메서드로 시작하지 않는 것입니다. 구체적인 클래스와 공개 API로 시작한 다음 일반적인 기능을 리팩토링합니다.