모의 객체

Mock object

객체 지향 프로그래밍에서 모의 객체는 대부분 소프트웨어 테스트 이니셔티브의 일부로서 통제된 방식으로 실제 객체의 동작을 모방하는 시뮬레이션 객체를 말한다.프로그래머는 일반적으로 자동차 설계자가 충돌 시험 인체모형을 사용하여 차량 충돌 시 사람의 동적 행동을 시뮬레이션하는 것과 거의 동일한 방법으로 다른 물체의 동작을 시험하기 위해 모의 객체를 만든다.이 기술은 일반 프로그래밍에도 적용된다.

동기

단위 시험에서 모의 물체는 복잡하고 실제 물체의 동작을 시뮬레이션할 수 있으며 따라서 실제 물체가 단위 시험에 통합될 수 없거나 비현실적일 때 유용하다.물체가 다음과 같은 특성을 가진 경우, 그 자리에 모의 물체를 사용하는 것이 유용할 수 있다.

  • 물체는 비-반복적인 결과(예: 현재 시간 또는 현재 온도)를 제공한다.
  • 생성 또는 재현하기 어려운 상태(예: 네트워크 오류)
  • 속도가 느림(예: 테스트 전에 초기화해야 하는 전체 데이터베이스)
  • 아직 존재하지 않거나 행동을 바꿀 수 있다.
  • 그것은 (실제 과업이 아닌) 시험 목적만을 위한 정보와 방법을 포함해야 할 것이다.

예를 들어, 특정 시간에 벨이 울리게 하는 알람 시계 프로그램은 시간 서비스에서 현재 시간을 얻을 수 있다.이를 테스트하기 위해, 테스트는 알람 시간까지 기다려야 벨이 제대로 울렸는지 여부를 알 수 있다.실시간 서비스 대신 모의시간 서비스를 이용할 경우 실시간에 관계없이 벨링 시간(또는 다른 시간)을 제공하도록 프로그래밍할 수 있어 알람시계 프로그램을 분리해 테스트할 수 있다.

기술적 세부사항

모의 오브젝트는 실제 오브젝트와 동일한 인터페이스를 가지고 있어 클라이언트 오브젝트가 실제 오브젝트를 사용하고 있는지 또는 모의 오브젝트를 사용하고 있는지 여부를 계속 모를 수 있다.이용 가능한 많은 모의 객체 프레임워크는 프로그래머가 모의 객체에 대해 어떤 방법이, 어떤 순서로 호출될 것인지, 어떤 매개변수가 그들에게 전달될 것인지, 그리고 어떤 값이 반환될 것인지를 지정할 수 있도록 한다.그러므로 네트워크 소켓과 같은 복잡한 물체의 동작은 모의 물체에 의해 모방될 수 있으며, 프로그래머는 시험 대상 물체가 그러한 모의 물체가 있을 수 있는 광범위한 상태에 적절하게 반응하는지 여부를 발견할 수 있다.

모크, 가짜, 스터브

모조품, 가짜, 단조품 사이의 분류는 문헌 전체에 걸쳐 매우 일관성이 없다.[1][2][3][4][5][6]그러나 문헌 간에 일관성은 모두 동일한 인터페이스를 노출함으로써 시험 환경에서 생산 객체를 나타낸다는 것이다.

모의, 가짜 또는 스터브 중에서 가장 단순한 것은 일관성이 없지만, 가장 단순한 것은 항상 미리 계획된 응답을 반환한다(메서드 스텁에서처럼).스펙트럼의 반대편에서는 가장 복잡한 물체가 완전한 논리, 예외 등을 가지고 생산 물체를 완전히 시뮬레이션할 것이다.모의, 가짜, 단조로운 3인방 중 어떤 것이 그러한 정의에 맞는지 아닌지는 다시 한번 문학 전반에 걸쳐 일관성이 없다.

예를 들어, 복잡성 스펙트럼의 양 끝 사이의 모의, 가짜 또는 스터브 방법 구현에는 각 통화의 맥락을 조사하기 위한 주장이 포함될 수 있다.예를 들어, 모의 객체는 자신의 방법이 호출되는 순서를 주장하거나, 또는 방법 호출에 걸쳐 데이터의 일관성을 주장할 수 있다.

'단위시험의[7] 기술'이라는 책에서 모의실험은 물체와의 상호작용이 일어났는지 여부를 검증함으로써 시험의 실패 또는 통과 여부를 결정하는 데 도움을 주는 가짜 물체로 묘사된다.다른 모든 것은 그루브라고 정의되어 있다.그 책에서 가짜는 진짜가 아닌 어떤 것이라도 되는 것인데, 그 용법에 근거하여 가짜는 단조롭거나 조롱거리가 될 수 있다.

기대치 설정

권한 부여 하위 시스템이 모의된 예를 생각해 보십시오.모의 객체는 다음을 구현한다.isUserAllowed(task : Task) : boolean[8] 실제 권한 부여 클래스에서 그것과 일치시키는 방법.만약 그것이 또한 그것을 노출시킨다면 많은 이점이 뒤따른다.isAllowed : boolean실제 계급에는 존재하지 않는 재산이를 통해 테스트 코드는 사용자가 다음 호출에서 허가를 받거나 받지 않을 것이라는 예상을 쉽게 설정하여 두 경우 모두 시스템의 나머지 동작을 쉽게 테스트할 수 있다.

마찬가지로, 모의 전용 설정은 하위 시스템에 대한 후속 호출로 인해 하위 시스템에 예외가 발생하거나 응답하지 않고 중단되거나 반환되도록 보장할 수 있다.null등. 따라서 백엔드 서브시스템에서 예상되는 응답뿐만 아니라 실제적인 고장 조건에 대한 고객 행동을 개발하고 테스트할 수 있다.이러한 간단하고 유연한 모의 시스템이 없다면, 이러한 각각의 상황을 시험하는 것은 그들에게 적절한 고려를 주기에는 너무 힘든 일일지도 모른다.

로그 문자열 작성 중

모의 데이터베이스 오브젝트save(person : Person)메소드는 구현 코드를 많이 포함하지 않을 수 있다.그것은 저장용으로 전달된 개인 개체의 존재와 타당성을 확인할 수 있지만(위의 가짜 대 모의 토론 참조), 그 이상 다른 구현은 없을 수 있다.

이것은 놓친 기회다.모의 방법은 공개 로그 문자열에 항목을 추가할 수 있다.항목은 "저장된 사용자"[9]: 146–7 이상이어야 하며, 이름 또는 ID와 같은 사용자 오브젝트 인스턴스의 일부 세부사항을 포함할 수 있다.모의 데이터베이스와 관련된 다양한 일련의 작업 후에 테스트 코드가 로그 문자열의 최종 내용도 확인한다면 각 경우에 예상되는 데이터베이스 저장 횟수가 정확히 수행되었는지 확인할 수 있다.이렇게 하면 눈에 보이지 않는 성능 저하시킬 수 있는 버그를 찾을 수 있다. 예를 들어, 데이터 손실에 불안해하는 개발자가 반복적인 통화 내용을 코딩한 경우save()한 사람이 충분히 살 수 있었을 텐데

테스트 주도형 개발에 사용

TDD(Test-Driven Development) 방식으로 작업하는 프로그래머는 소프트웨어를 작성할 때 모의 사물을 사용한다.모의 객체는 보다 복잡한 실제 객체의 인터페이스 요건을 충족하며, 따라서 프로그래머가 복잡한 기본 클래스를 호출하거나 협업 클래스를 호출하지 않고 한 영역에서 쓰기 및 단위 테스트 기능을 가능하게 한다.[9]: 144–5 모의 객체를 사용하면 개발자들이 종속성에 대한 걱정 없이 테스트 중인 시스템의 동작에 테스트의 초점을 맞출 수 있다.예를 들어 특정 상태에 있는 여러 개체를 기반으로 복잡한 알고리즘을 시험하는 것은 실제 물체 대신 모의 물체를 사용하여 명확하게 표현할 수 있다.

복잡성 문제와 이러한 우려의 분리를 통해 얻을 수 있는 이점은 차치하고 실질적인 속도 문제가 관련되어 있다.TDD를 사용하여 현실적인 소프트웨어를 개발하는 것은 수백 개의 단위 시험을 쉽게 수반할 수 있다.만약 이러한 많은 것들이 데이터베이스, 웹 서비스, 그리고 다른 처리되지 않은 혹은 네트워크화된 시스템과의 통신을 유도한다면, 유닛 테스트의 집합은 너무 느려져서 정기적으로 실행될 수 없을 것이다.이는 결국 나쁜 습관과 개발자가 TDD의 기본 원칙을 유지하기를 꺼리는 결과를 초래한다.

모의 물체가 실제 물체로 대체될 때, 엔드투엔드 기능성은 추가 시험이 필요할 것이다.이것은 단위 테스트가 아니라 통합 테스트가 될 것이다.

제한 사항

모의 물체를 사용하면 단위 시험을 시험 중인 코드의 구현과 밀접하게 결합할 수 있다.예를 들어, 많은 모의 객체 프레임워크는 개발자가 모의 객체 방법이 시험 중인 실제 객체에 의해 호출된 순서와 횟수를 확인할 수 있도록 한다. 따라서 후속적으로 시험 중인 코드의 리팩터링은 모든 모의 객체 방법이 이전 im의 계약에 여전히 복종함에도 불구하고 시험을 실패할 수 있다.염기 서열이는 단위 시험이 방법의 내부 구현보다는 외부 행동을 시험해야 함을 보여준다.단위 시험의 일부로서 모의 물체를 과도하게 사용하면 리팩터링이 이루어짐에 따라 시스템 진화 중에 시험 자체에 대해 수행되어야 하는 정비의 양이 급격하게 증가할 수 있다.진화 중 그러한 시험의 부적절한 유지보수는 버그를 놓치게 할 수 있으며 그렇지 않으면 실제 등급의 인스턴스를 사용하는 단위 시험에 의해 잡힐 수 있다.반대로 한 가지 방법을 단순히 조롱하는 것은 전체 실제 클래스를 설정하는 것보다 훨씬 적은 구성을 필요로 할 수 있고 따라서 유지보수의 필요성을 줄일 수 있다.

모의 오브젝트는 자신이 조롱하는 오브젝트의 행동을 정확하게 모델링해야 하는데, 조롱하는 오브젝트가 다른 개발자나 프로젝트에서 온 것이라면, 혹은 아직 작성조차 되지 않은 경우에는 달성하기 어려울 수 있다.동작이 올바르게 모델링되지 않은 경우 장치 테스트는 장치 테스트가 실행 중인 동일한 조건에서 런타임에 고장이 발생하여 장치 테스트가 부정확하게 되더라도 패스를 등록할 수 있다.[10]

참고 항목

참조

  1. ^ "Let's speak the same language (Fake, Stubs and Mocks)".
  2. ^ "behind the times: Mocks and Stubs aren't Spies". 21 October 2007.
  3. ^ "Mocks, Fakes, Stubs and Dummies at XUnitPatterns.com".
  4. ^ "What's the difference between a mock & stub?".
  5. ^ "What's the difference between faking, mocking, and stubbing?".
  6. ^ Feathers, Michael (2005). "Sensing and separation". Working effectively with legacy code. NJ: Prentice Hall. p. 23 et seq. ISBN 0-13-117705-2.
  7. ^ Osherove, Roy (2009). "Interaction testing with mock objects et seq". The art of unit testing. Manning. ISBN 978-1-933988-27-6.
  8. ^ 이러한 예는 Unified Modeling Language에서 사용되는 것과 유사한 명명법을 사용한다.
  9. ^ a b Beck, Kent (2003). Test-Driven Development By Example. Boston: Addison Wesley. ISBN 0-321-14653-0.
  10. ^ InJava.com to Mocking O'Reilly Media

외부 링크