Xcode에서 개인 메서드의 단위 테스트
장난감 프로젝트에서 테스트 주도 개발을 시도하고 있습니다. 내 클래스에 대한 공용 인터페이스에서 작동하는 테스트를 얻을 수 있습니다 (테스트중인 메서드보다 더 많은 테스트 코드를 작성하고 있기 때문에 여전히 울타리에 있습니다).
나는 공용 인터페이스를 깨끗하게 유지하기를 좋아하기 때문에 많은 개인 메서드를 사용하는 경향이 있습니다. 그러나 여전히 이러한 방법에 대한 테스트를 사용하고 싶습니다.
Cocoa는 동적 언어이기 때문에 여전히 이러한 private 메서드를 호출 할 수 있지만 테스트에서 내 클래스가 이러한 메서드에 응답하지 않을 수 있다는 경고가 표시됩니다. 경고없이 컴파일하고 싶기 때문에 여기에 내 질문이 있습니다.
- Xcode에서 이러한 경고를 어떻게 해제합니까?
- 이 경고를 끌 수있는 다른 방법이 있습니까?
- '화이트 박스'테스트를 시도하는 데 문제가 있습니까?
Xcode에서 이러한 경고를 어떻게 해제합니까?
하지마.
이 경고를 끌 수있는 다른 방법이 있습니까?
하지마.
'화이트 박스'테스트를 시도하는 데 문제가 있습니까?
아니.
해결책은 개인 메서드를 자체 헤더의 범주로 이동하는 것입니다. 이 헤더를 실제 클래스 및 테스트 케이스 클래스 구현 파일로 가져 오십시오.
Objective-C에는 실제로 "사설 방법"과 같은 것이 없으며 동적 언어이기 때문 만은 아닙니다. 의도적으로 Objective-C에는 ivar에 대한 가시성 수정자가 있지만 메서드에는 해당되지 않습니다. 원하는 메서드를 호출 할 수있는 것은 우연이 아닙니다.
@Peter 의 제안은 훌륭한 것입니다. 그의 대답을 보완하기 위해 내가 사용한 대안은 (개인 메서드에 대한 헤더가 필요하지 않거나 필요하지 않을 때) 단위 테스트 파일 자체에 범주 를 선언하는 것 입니다. (저는 @interface MyClass (Test)이름으로 사용 합니다.) 이것은 테스트중인 클래스가 액세스 할 수있는 ivar에 액세스하는 것과 같이 릴리스 코드에서 불필요하게 부풀려지는 메서드를 추가하는 좋은 방법입니다. (이것은 속성을 사용할 때 분명히 문제가되지 않습니다.)
이 접근 방식을 사용하면 내부 상태를 쉽게 노출하고 확인할 수있을뿐만 아니라 테스트 전용 메서드를 추가 할 수도 있습니다. 예를 들어, 이 단위 테스트 파일 에서 -isValid이진 힙의 정확성을 확인 하는 방법을 작성했습니다 . 프로덕션에서이 방법은 힙이 유효하다고 가정하기 때문에 공간 낭비가 될 것입니다. 코드를 수정하면 단위 테스트 회귀를 테스트 할 때만 신경을 씁니다.
다른 질문에 답이있는 것 같습니다. Xcode에서 경고를 억제하는 방법이 있습니까?
개인 헤더를 갖거나 자신의 카테고리를 정의하는 것이 아마도 더 정확한 해결책 일 수 있지만 또 다른 매우 간단한 해결책이 있습니다. 메소드를 호출하기 전에 객체를 (id)로 캐스트하십시오.
프라이빗 메서드 구현을 여러 소스 파일에 배포하지 않으려는 경우 Category 솔루션에 대한 개선은 기존 클래스에서 가져온 헤더 파일에 Extension (본질적으로 익명 범주 -Apple의 설명서 참조)을 정의하는 것입니다. '구현 및 관련 단위 테스트 소스 파일.
확장을 사용하면 컴파일러가 private 메서드의 구현이 기본 @implementation 블록에없는 경우 경고 할 수 있습니다. 이 링크 는 그것을 잘 보여줍니다.
며칠 전 TDD를 시작했을 때도 같은 문제를 다루고있었습니다. Test-Driven iOS Development 책 에서 매우 흥미로운 관점을 발견했습니다 .
나는 종종 "내 개인 방법을 테스트해야합니까?"라는 질문을 받았습니다. 또는 관련 질문 "내 개인 메서드를 어떻게 테스트해야합니까?" 두 번째 질문을하는 사람들은 첫 번째 질문에 대한 대답이 "예"라고 가정했으며 이제 테스트 스위트에서 클래스의 개인 인터페이스를 노출 할 방법을 찾고 있습니다.
내 대답은 미묘한 사실에 대한 관찰에 의존합니다. 당신은 이미 당신의 사적인 방법을 테스트했습니다. 테스트 중심 개발에서 일반적으로 사용되는 빨강-녹색-리팩터링 접근 방식을 따라 개체의 공용 API를 설계하여 해당 개체가 수행해야하는 작업을 수행합니다. 테스트에서 지정한 작업과 테스트를 계속 실행하여 어떤 것도 깨지지 않았 음을 보장하므로 적절하다고 판단되는대로 클래스의 내부 배관을 자유롭게 구성 할 수 있습니다.
수행중인 모든 작업은 이미 테스트가있는 동작을 리팩토링하는 것이므로 비공개 메서드는 이미 테스트되었습니다. 공개 메소드의 구현을 정리할 기회가있을 때만 작성하기 때문에 비공개 메소드가 테스트되지 않았거나 불완전하게 테스트되는 상황이되어서는 안됩니다. 이렇게하면 공용 메서드에서 확실히 호출되기 때문에 테스트 중에 호출해야하는 클래스를 지원하기위한 전용 메서드 만 존재합니다.
쉬운 일. 단계 : 1.-(NSString *) getTestString; 인터페이스 Foo에 대한 대상 m 파일에서
단위 테스트 파일에 카테고리를 추가하십시오.
@ 인터페이스 DemoHomeViewController ()-(NSString *) getTestString; @종료
그런 다음 지금 원하는 것을하십시오.
참고 URL : https://stackoverflow.com/questions/1098550/unit-testing-of-private-methods-in-xcode
'programing' 카테고리의 다른 글
| 데이터베이스의 비즈니스 로직과 코드? (0) | 2020.11.23 |
|---|---|
| Bash에서 "$ @"와 "$ *"의 차이점은 무엇입니까? (0) | 2020.11.23 |
| Java의 시간 상수? (0) | 2020.11.22 |
| web2py를 사용하는 사람이 있습니까? (0) | 2020.11.22 |
| html 버튼에 react-router 링크 감싸기 (0) | 2020.11.22 |