다른 답변은 조롱이 무엇인지 설명합니다. 다른 예를 들어 설명해 드리겠습니다 . 그리고 믿습니다. 실제로 생각보다 훨씬 간단합니다.
tl; dr 원래 클래스의 인스턴스입니다. 여기에는 다른 데이터가 주입되므로 주입 된 부품 을 테스트하지 않고 구현 세부 사항 테스트 에만 집중합니다 . 말고 클래스 / 함수 하십시오.
간단한 예 :
class Foo {
func add (num1: Int, num2: Int) -> Int { // Line A
return num1 + num2 // Line B
}
}
let unit = Foo() // unit under test
assertEqual(unit.add(1,5),6)
보시다시피, 나는 LineA를 테스트하지 않습니다. 즉 입력 매개 변수를 확인하지 않습니다. num1, num2가 정수인지 확인하지 않습니다. 나는 그것에 대해 어떤 주장도 없다.
LineB (내 구현 ) 가 모의 값을 제공 하는지 확인하기 만 테스트 1하고 있습니다.5 나는 예상대로하고있다.
분명히 말해서 이것은 훨씬 더 복잡해질 수 있습니다. 매개 변수는 개인, 주소와 같은 사용자 정의 오브젝트이거나 구현 세부 사항이 둘 이상일 수 있습니다.+ . 그러나 테스트 논리는 동일합니다.
비 코딩 예 :
공항 보안을 위해 전자 장치의 유형과 브랜드 이름을 식별하는 시스템을 구축한다고 가정합니다. 기계는 카메라로 보는 것을 처리하여이를 수행합니다.
이제 관리자가 문을 걸어 단위 테스트를 요청합니다.
그런 다음 개발자는 MacBook Pro, Google Nexus, 바나나, iPad 등 1000 개의 실제 개체를 가져 와서 테스트하여 모두 작동하는지 확인할 수 있습니다.
그러나 당신은 또한 조롱 을 사용할 수 있습니다 동일한 모양의 MacBook Pro (실제 내부 부품 없음) 또는 플라스틱 바나나와 같은 물건 . 1000 개의 실제 랩톱 및 썩은 바나나에 투자하지 않아도됩니다.
요점은 바나나가 가짜인지 테스트하지 않는 것입니다. 랩톱이 가짜인지 테스트하지도 않습니다. 컴퓨터에 바나나가 표시 not an electronic device되고 MacBook Pro에 대해서는 다음과 같이 표시 Laptop, Apple됩니다. 기계의 탐지 결과는 가짜 / 모의 전자 장치와 실제 전자 장치에서 동일해야합니다.
위에서 언급 한 논리는 실제 코드의 단위 테스트에도 적용됩니다. 그것은 함수가 실제 입력 (및 상호 작용) 에서 얻 거나 모의 한 실제 값과 동일하게 작동해야한다는 것입니다단위 테스트 중에 주입 한 값. 또한 실제 바나나 또는 MacBook을 사용하지 않는 방법과 마찬가지로 단위 테스트 (및 조롱)를 사용하면 서버가 500, 403, 200 등의 상태 코드를 반환하는 작업을 수행하지 않아도됩니다 (강제 500을 트리거하는 서버는 서버가 중단 된 경우에만, 200은 서버가 가동 된 경우에만 가능합니다. 서버를 위아래로 전환하는 사이에 10 초 동안 계속 기다려야하는 경우 100 개의 네트워크 중심 테스트를 실행하기가 어렵습니다). 대신 상태 코드 500, 200, 403 등으로 응답을 주입 / 모의하고 주입 / 모의 값으로 장치 / 기능을 테스트합니다.
코딩 예 :
iOS 애플리케이션을 작성 중이고 네트워크 호출이 있다고 가정 해 봅시다. 당신의 임무는 애플리케이션 을 테스트하는 것 입니다. 네트워크 호출이 예상대로 작동하는지 테스트 / 식별하는 것은 귀하의 책임이 아닙니다. 그것을 테스트하는 것은 다른 당사자의 (서버 팀) 책임입니다. 이 (네트워크) 종속성을 제거하고 그 주위 에서 작동하는 모든 코드를 계속 테스트해야합니다 .
네트워크 호출은 JSON 응답으로 다른 상태 코드 404, 500, 200, 303 등을 반환 할 수 있습니다.
앱은 모든 앱에서 작동한다고 가정 합니다 (오류의 경우 앱에서 예상 오류가 발생 함). 조롱으로하는 일은 '실제 네트워크 호출을 만들고 네트워크 응답을 기다리지 않고 '실제 와 같은 네트워크 응답 (JSON 파일의 200 코드와 유사)을 만들고 코드 를 테스트하는 것 입니다. 모든 종류의 네트워크 응답에 대해 네트워크 응답을 수동으로 하드 코딩 / 반환하고 앱이 예상대로 작동하는지 확인합니다. (당신은 결코 그 책임이 아니기 때문에, 잘못된 데이터와 200을 테스트 /지지 않습니다, 귀하의 책임 테스트하는 것입니다 귀하의 정확한 (200)와 응용 프로그램을, 또는 400, 500, 당신 테스트의 경우 앱 올바른 오류가 발생하는 경우)
현실과 유사한 상상을 창조하는 것을 조롱이라고합니다.
이렇게하려면 원래 코드를 사용할 수 없습니다 (원래 코드에는 미리 삽입 된 응답이 없습니다.)? 당신은 해야한다 그것에 무언가를 추가 분사 / 일반적으로 필요하지 않은 그 더미 데이터 (또는 클래스의 일부)를 삽입합니다.
당신이 인스턴스를 원래 클래스를 만들고 어떤 추가 그래서 당신이 그것을 필요하고 테스트 (여기에 네트워크 HttpResponse에, 데이터 또는 실패의 경우에있는 올바른 Errorstring이, HttpResponse에 통과) 조롱 클래스를.
간단히 말하면, 조롱은 테스트 대상 을 단순화 하고 제한 하고 클래스가 의존하는 것을 피드하는 것입니다. 이 예제에서는 테스트를 피할 네트워크는 자신을 호출 , 대신 시험 예상대로 앱 작동 여부를 주입 출력 / 답변으로 -에 의해 조롱 클래스
말할 것도없이, 각 네트워크 응답을 개별적으로 테스트하십시오.
이제 내가 항상 생각했던 질문은 다음과 같습니다. 계약 / 종료 지점 및 기본적으로 API의 JSON 응답이 지속적으로 업데이트됩니다. 이를 고려하여 단위 테스트를 작성하려면 어떻게해야합니까?
이에 대해 자세히 설명하려면 모델에 키 / 필드라는 이름이 필요하다고 가정 해 보겠습니다 username. 이것을 테스트하고 테스트를 통과합니다. 2 주 후 백엔드는 키 이름을로 변경합니다 id. 테스트는 여전히 통과합니다. 권리? 또는 아닙니다?
모의 내용을 업데이트하는 것은 백엔드 개발자의 책임입니까? 업데이트 된 모형을 제공하는 것이 당사 계약의 일부 여야합니까?
위의 문제에 대한 대답은 다음과 같습니다. 단위 테스트 + 클라이언트 측 개발자로서의 개발 프로세스는 오래된 모의 응답을 포착해야합니다. 어떻게 물어 보면? 정답은 :
우리의 실제 응용 프로그램은 업데이트 된 API를 사용하지 않으면 실패합니다 (또는 실패하지는 않지만 원하는 동작을하지 못합니다). 그래서 실패하면 ... 개발 코드를 변경합니다. 다시 테스트에 실패합니다. 수정해야합니다. (실제로 TDD 프로세스를 올바르게 수행하려면 테스트를 작성하지 않으면 필드에 대한 코드를 작성해서는 안됩니다. 실패한 다음 실제 개발 코드를 작성하여 작성하십시오.)
이것은 백엔드가 "모의를 업데이트했습니다"라고 말할 필요가 없다는 것을 의미합니다. 결국 코드 개발 / 디버깅을 통해 발생합니다. ّ 개발 과정의 모든 부분이기 때문에! 백엔드가 모의 응답을 제공한다면 더 쉽습니다.
이것에 대한 나의 요점은 ( 모의 API 응답 업데이트를 자동화 할 수없는 경우) JSON의 수동 업데이트 및 짧은 회의를 통해 값이 최신 상태인지 확인하는 프로세스의 일부가 될 것입니다.
이 섹션은 CocoaHead 밋업 그룹의 느슨한 토론 덕분에 작성되었습니다
iOS 개발자 만 해당 :
조롱의 좋은 예는 Natasha Muraschev의 실용 프로토콜 지향 강연 입니다. 슬라이드가 실제 비디오와 동기화되지 않을 수 있지만 18:30 분으로 건너 뛰십시오. 🤷♂️
나는이 부분을 대본에서 정말 좋아한다.
이것은 테스트 중이므로 ...에서 get함수 Gettable가 호출 되는지 확인 하고 함수가 이론적으로 어디서나 음식 항목 배열을 할당 할 수 있기 때문에 확인하고 싶습니다 . 호출되는지 확인해야합니다.