NMock과 VS 2011 Fakes Framework와 같은 Mock 프레임 워크의 차이점에 대해 약간 혼란스러워합니다. MSDN을 살펴보면 Fakes를 사용하면 RhinoMock 또는 NMock처럼 종속성을 모의 할 수 있지만 접근 방식은 다르지만 Fakes는이 기능을 구현하는 코드를 생성하지만 Mocks 프레임 워크는 그렇지 않습니다. 내 이해가 맞습니까? 가짜는 또 다른 모의 프레임 워크 일뿐
NMock과 VS 2011 Fakes Framework와 같은 Mock 프레임 워크의 차이점에 대해 약간 혼란스러워합니다. MSDN을 살펴보면 Fakes를 사용하면 RhinoMock 또는 NMock처럼 종속성을 모의 할 수 있지만 접근 방식은 다르지만 Fakes는이 기능을 구현하는 코드를 생성하지만 Mocks 프레임 워크는 그렇지 않습니다. 내 이해가 맞습니까? 가짜는 또 다른 모의 프레임 워크 일뿐
답변:
귀하의 질문은 MS Fakes 프레임 워크가 NMock과 어떻게 다른지에 관한 것이었고 다른 답변이 그 중 일부를 해결 한 것으로 보이지만 여기에 그들이 어떻게 동일하고 어떻게 다른지에 대한 추가 정보가 있습니다. NMock은 RhinoMocks 및 Moq 와도 유사하므로 NMock과 함께 그룹화합니다.
NMock / RhinoMocks / Moq와 MS Fakes Framework 사이에는 3 가지 주요 차이점이 있습니다.
MS fakes 프레임 워크는 제네릭 형식 대신 이전 버전의 Visual Studio의 접근 자처럼 생성 된 코드를 사용합니다. 종속성에 대해 가짜 프레임 워크를 사용하려는 경우 종속성이 포함 된 어셈블리를 테스트 프로젝트의 참조에 추가 한 다음 마우스 오른쪽 단추를 클릭하여 테스트 double (스텁 또는 shim)을 생성합니다. 그런 다음 테스트 할 때 실제로 생성 된 클래스를 대신 사용합니다. NMock은 제네릭을 사용하여 동일한 작업을 수행합니다 (예 :) IStudentRepository studentRepository = mocks.NewMock<IStudentRepository>(). 제 생각에는 MS Fakes 프레임 워크 접근 방식은 실제 인터페이스가 아닌 생성 된 클래스에 대해 실제로 작업하기 때문에 테스트 내에서 코드 탐색 및 리팩토링을 금지합니다.
MS fakes 프레임 워크는 스텁과 두더지 (심)를 제공하는 반면 NMock, RhinoMocks 및 Moq는 모두 스텁과 모의를 제공합니다 . 나는 모의를 포함하지 않기로 한 MS의 결정을 정말로 이해하지 못하며 개인적으로 아래에 설명 된 이유로 두더지의 팬이 아닙니다.
MS fakes 프레임 워크를 사용하면 스텁 할 메서드의 대체 구현을 제공합니다. 이러한 대체 구현 내에서 반환 값을 지정하고 메서드 호출 방법 또는 여부에 대한 정보를 추적 할 수 있습니다. NMock, RhinoMocks 및 Moq를 사용하여 모의 객체를 생성 한 다음 해당 객체를 사용하여 스텁 반환 값을 지정하거나 상호 작용 (메소드 호출 여부 및 방법)을 추적합니다. 나는 MS 가짜 접근 방식이 더 복잡하고 덜 표현 적이라는 것을 알았습니다.
프레임 워크가 제공하는 것의 차이점을 명확히하기 위해 NMock, RhinoMocks 및 Moq는 모두 두 가지 유형의 테스트 복식 (스텁 및 모의)을 제공합니다. 가짜 프레임 워크는 스텁과 두더지 (심이라고 부름)를 제공하며 안타깝게도 모의는 포함하지 않습니다. NMock과 MS Fakes의 차이점과 유사점을 이해하려면 이러한 다양한 유형의 테스트 복식이 무엇인지 이해하는 것이 좋습니다.
스텁 : 스텁은 테스트중인 메소드에 의해 두 배가되는 테스트 요청을받을 메소드 또는 속성에 대한 값을 제공해야 할 때 사용됩니다. 예를 들어, 테스트중인 메서드가 IStudentRepository 테스트 double의 DoesStudentExist () 메서드를 호출 할 때 true를 반환하고 싶습니다.
NMock과 MS 가짜의 스텁 아이디어는 동일하지만 NMock을 사용하면 다음과 같이 할 수 있습니다.
Stub.On(mockStudentRepository).Method("DoesStudentExist").Will(Return.Value(true));
그리고 MSFakes를 사용하면 다음과 같이 할 수 있습니다.
IStudentRepository studentRepository = new DataAccess.Fakes.StubIStudentRepository() // Generated by Fakes.
{
DoesStudentExistInt32 = (studentId) => { return new Student(); }
};
MS Fakes 예제에서 DoesStudentExist 메서드에 대한 완전히 새로운 구현을 만들었습니다. 테스트). 솔직히 말해서 NMock 구현은 메서드 이름을 식별하기 위해 문자열을 사용하기 때문에 저를 괴롭 힙니다. (NMock이 어떻게 사용되는지 잘못 이해했다면 용서 해주세요.)이 접근 방식은 실제로 리팩토링을 방해하므로 NMock보다 RhinoMocks 또는 Moq를 적극 권장합니다.
모의 : 모의는 테스트중인 메서드와 종속성 간의 상호 작용을 확인하는 데 사용됩니다. NMock을 사용하면 다음과 유사한 기대치를 설정하여이를 수행합니다.
Expect.Once.On(mockStudentRepository).Method("Find").With(123);
이것이 제가 NMock보다 RhinoMocks와 Moq를 선호하는 또 다른 이유입니다. :
stubStudentRepository.AssertWasCalled( x => x.Find(123));
다시 말하지만, RhinoMocks는 메서드를 식별하기 위해 문자열 대신 람다를 사용합니다. ms fakes 프레임 워크는 모의를 전혀 제공하지 않습니다. 이는 스텁 아웃 구현 (위의 스텁 설명 참조)에서 나중에 올바르게 설정되었는지 확인할 변수를 설정해야 함을 의미합니다. 다음과 같이 보일 것입니다.
bool wasFindCalled = false;
IStudentRepository studentRepository = new DataAccess.Fakes.StubIStudentRepository()
{
DoesStudentExistInt32 = (studentId) =>
{
wasFindCalled = true;
return new Student();
}
};
classUnderTest.MethodUnderTest();
Assert.IsTrue(wasFindCalled);
스텁에서 호출을 추적 한 다음 나중에 테스트에서 주장해야하므로이 접근 방식이 약간 복잡하다는 것을 알았습니다. NMock, 특히 RhinoMocks 예제가 더 표현력이 있다는 것을 알았습니다.
두더지 (심즈) : 솔직히 말해서 나는 두더지가 남용 될 가능성이 있기 때문에 좋아하지 않습니다. 단위 테스트 (특히 TDD)에 대해 제가 좋아하는 것 중 하나는 코드를 테스트하면 잘못된 코드를 작성한 위치를 이해하는 데 도움이된다는 것입니다. 잘못 작성된 코드를 테스트하기가 어렵 기 때문입니다. 두더지는 실제로 주입되지 않은 종속성에 대해 테스트하거나 개인 메서드를 테스트 할 수 있도록 설계 되었기 때문에 두더지를 사용할 때는 사실이 아닙니다. 다음과 같이 ShimsContext를 사용한다는 점을 제외하면 스텁과 유사하게 작동합니다.
using (ShimsContext.Create())
{
System.Fakes.ShimDateTime.NowGet = () => { return new DateTime(fixedYear, 1, 1); };
}
shim에 대한 나의 걱정은 사람들이 그들을 "단위 테스트를위한 더 쉬운 방법"으로보기 시작할 것이라는 것입니다. 그것은 당신이해야하는 방식으로 코드를 작성하도록 강요하지 않기 때문입니다. 이 개념에 대한 자세한 내용은이 게시물을 참조하십시오.
가짜 프레임 워크와 관련된 몇 가지 우려 사항에 대한 자세한 내용은 다음 게시물을 참조하십시오.
RhinoMocks 학습에 관심이 있으시다면 여기 Pluralsight 교육 동영상이 있습니다 (전체 공개-이 과정을 작성하고 조회수에 대한 로열티를 받지만이 토론에 적용되는 것 같아 여기에 포함하겠습니다).
당신은 맞지만 이야기에 더 많은 것이 있습니다. 이 답변에서 제거해야 할 가장 중요한 사항은 다음과 같습니다.
아키텍처는 Fakes와 mock의 목발에 의존하는 대신 스텁과 종속성 주입을 적절히 사용해야합니다.
가짜와 모의는 다음과 같이 변경하지 말거나 변경할 수없는 코드를 테스트하는 데 유용합니다.
Shims (개발 중 "두더지"라고 함)는 실제로 우회 호출 방식으로 작동하는 조롱 프레임 워크입니다. 모의 작업을 힘들게 만드는 대신 (예, Moq을 사용하는 것도 비교적 고통 스럽습니다!) shim은 단순히 이미 배치 된 프로덕션 코드 객체를 사용합니다. Shim은 단순히 프로덕션 대상에서 테스트 델리게이트로 호출을 다시 라우팅합니다.
스텁 은 대상 프로젝트의 인터페이스에서 생성됩니다. Stub 객체는 인터페이스의 구현입니다. Stub 유형을 사용하는 이점은 많은 일회성 사용 스텁으로 테스트 프로젝트를 복잡하게 만들지 않고 스텁을 빠르게 생성 할 수 있다는 것입니다. 물론 여러 테스트에서 사용할 수 있도록 구체적인 스텁을 작성해야합니다.
Fakes (Shims, Mocks 및 Stub 유형)를 효율적으로 구현하려면 익숙해지는 데 약간의 시간이 걸리지 만 그만한 가치가 있습니다. Shims / Mole, Mocks 및 Stub 유형을 사용하여 개인적으로 몇 주 동안 개발 시간을 절약했습니다. 여러분이 저만큼이나 기술을 재미있게 즐기 셨기를 바랍니다!
내가 이해 한대로 Visual Studio 팀은 .NET에서 사용할 수있는 다양한 모의 라이브러리와 경쟁하지 않기를 원했습니다. MS는 종종 이와 같은 어려운 결정에 직면합니다. 특정 기능을 제공하지 않으면 ( "MS는 왜 우리에게 모의 라이브러리를 제공하지 않는가? 모의는 일반적인 요구 사항입니까?") 저주를 받고 ( "Microsoft가 그렇게 공격적으로 행동하고 자연적인 지지자들이 시장에서 나오지 않습니까? ") 항상 그런 것은 아니지만 매우 자주 사용 가능하고 호평을받는 기술에 대한 자체 대안을 제공하지 않기로 결정합니다. 여기에 해당하는 것 같습니다.
Fakes의 shim 기능은 정말 정말 유용합니다. 물론 위험이 있습니다. 필요한 경우에만 이것을 사용하려면 약간의 규율이 필요합니다. 그러나 그것은 큰 격차를 메 웁니다. 나의 주된 불만은 VS 2012의 Ultimate 에디션에서만 제공되므로 .NET 개발 커뮤니티의 하위 섹션에서만 사용할 수 있다는 것입니다. 유감입니다.
가짜에는 두 가지 종류의 "가짜"개체가 포함됩니다. "스텁"이라고하는 첫 번째는 기본적으로 자동 생성 된 더미이며 기본 동작을 재정 의하여 더 흥미로운 모의로 만들 수 있습니다. 그러나 현재 사용 가능한 대부분의 모의 프레임 워크가 제공하는 기능 중 일부가 부족합니다. 예를 들어 스텁 인스턴스의 메서드가 호출되었는지 확인하려면 이에 대한 논리를 직접 추가해야합니다. 기본적으로 지금 수동으로 모의를 작성하는 경우 스텁은 개선 된 것처럼 보일 것입니다. 그러나 이미 더 완전한 기능을 갖춘 모의 프레임 워크를 사용하고 있다면 Fakes 스텁에서 누락 된 몇 가지 중요한 부분이 있다고 느낄 수 있습니다.
"shim"이라고하는 Fakes가 제공하는 다른 범주의 객체는 mock을 통한 표준 교체를 위해 적절하게 분리되지 않았거나 분리 될 수없는 종속성의 동작을 대체하는 메커니즘을 제공합니다. AFAIK, TypeMock은 현재 이러한 종류의 기능을 제공하는 주요 조롱 프레임 워크 중 하나입니다.
BTW, 이전에 Moles를 사용해 본 적이 있다면 Fakes는 본질적으로 동일한 것이며 마침내 Microsoft Research에서 실제 제품으로 나아갑니다.
Fake (Shim + Stub) 객체에 대해서는 위에서 잘 정의되어 있지만 마지막 주석의 마지막 단락이 전체 상황을 꽤 잘 요약 한 것 같습니다.
많은 사람들이 Fake (Shim + Stub) 개체가 일부 단위 테스트 사례에서 가질 수있는 좋은 자산이라고 주장하지만 단점은 Visual Studio 2012 또는 Visual Studio 2013을 사용하는지 여부에 관계없이 이러한 옵션 만 사용할 수 있다는 것입니다. Premium 또는 Ultimate 버전으로. IOW, 이것은 Pro 버전에서 이러한 가짜 (Shim + Stub)를 실행하지 않을 것임을 의미합니다.
Pro 버전에서 Fakes (Shim + Stub) 메뉴 옵션이 표시 될 수 있지만, 완전히 아무것도하지 않을 가능성이 매우 높습니다. 중요한 내용을 알려주는 컴파일 오류가 발생하지 않습니다. 옵션이 없습니다. 시간을 낭비하지 마십시오.
개발 팀에서 고려해야 할 중요한 요소입니다. 특히 다른 사람들이 Pro 버전을 사용하는 동안 Ultimate 버전을 사용하는 유일한 경우 ... 반면에 Moq는 사용하는 Visual Studio 버전에 관계없이 Nuget을 통해 쉽게 설치할 수 있습니다. 나는 Moq를 사용하는 데 아무런 문제가 없었습니다. 어떤 도구의 핵심은 그들이 무엇에 사용되는지, 그리고 그것들을 올바르게 사용하는 방법을 아는 것입니다.)