Autofixture: 선택적으로 AutoMoq에 대한 캐싱을 비활성화하시겠습니까?

결과 값을 캐싱하는 아이디어는 기본적으로 모든 메서드를 _pure_ 로 만드는 것이

테스트 중인 시스템이 순수 함수를 예상하지만 순수하지 않은 함수가 제공되면 테스트 결과 거짓 양성이 나올 수 있습니다. 예

// This method will return the expected result *if* `GetInt` is pure.
int Double(IDependency dep) {
    return dep.GetInt() + dep.GetInt();
}

Assert.Equal(dep.GetInt * 2, Double(dep));

반면에 테스트 중인 시스템이 순도를 가정하지 않는 경우 순수 또는 불순한 기능을 부여해도 아무런 차이가 없습니다.

따라서 이 기능을 구현할 때 순수 함수를 기본값으로 설정하는 것이 합리적이었습니다.

각 호출을 수동으로 설정하는 것 외에 AutoFixture에서 값이 필요할 때마다 조명기를 호출하도록 자동 생성된 모의를 구성하는 더 일반적이고 스마트한 방법이 있습니까?

_one_ 메서드에 대해 이 작업을 수행해야 하지만 여러 테스트에서 재사용 가능한 IConfiguration 넣을 것입니다.

여러 테스트에서 모든 방법에 대해 이 작업을 수행하려면 조금 더 많은 작업이 필요합니다.

• ReturnsUsingContext 의 새 구현을 정의합니다(IIRC, 현재 구현을 복사하고 104행을 제거하면 됩니다).
• MockVirtualMethodsCommand 재정의하고 ReturnsUsingContext 에 대한 호출을 새 메서드에 대한 호출로 바꿉니다.
• AutoConfiguredMoqCustomization 재정의하고 MockVirtualMethodsCommand 의 인스턴스화를 새 클래스의 인스턴스화로 바꿉니다.

우리는 이 동작을 구성할 수 있는 방법을 생각할 수도 있지만 이를 정당화할 만큼 수요가 높은지 확실하지 않습니다. 제 생각에는 이러한 변경을 가볍게 여겨서는 안 됩니다. 세분화된 사용자 지정은 우발적인 복잡성으로 이어질 수 있습니다. @ploeh , 이에 대해 어떻게 생각하십니까?

테스트 더블이 반환 값을 얻기 위해 AutoFixture로 다시 호출하도록 구성되어 있다고 생각했음을 인정합니다. AutoFixture에는 이미 수명 관리 메커니즘이 있으므로(정지 기능을 통해) AutoConfiguredMoqCustomization 가 자체 수명 관리자를 구현하여 AutoFixture 자체가 제공하는 컨트롤 표면을 무시한다는 것이 약간 놀랍습니다.

아주 좋은 지적입니다. Freeze 대해 그런 식으로 생각한 적이 없습니다. 이제 사용자 정의의 동작을 변경하는 것은 획기적인 변경이 될 것입니다. 제 생각에는... AutoFixture v4에서 변경되어야 한다고 생각하십니까?

테스트에서 문서화했거나 어떻게든 '약속'한 동작입니까?

놀랍게도, 아닙니다. 나는 내가 이것을 덮었다고 꽤 확신했지만, 나는 그렇지 않은 것 같다. 적어도 나는 이것을 다루는 어떤 테스트도 찾을 수 없었고, 그 라인을 제거해도 어떤 테스트도 실패하지 않았다. 그러나 IMO는 여전히 관찰 가능한 동작이며 이에 의존하는 코드가 있을 수 있습니다...

공정한 포인트. 지금 하나의 값으로 설정한 다음 AutoFixture 4로 전환할 때 전환하는 구성 값이 될 수 있습니까?

동의. 이러한 맥락에서 "구성 값"은 정확히 무엇을 의미합니까? MockType 클래스 내부의 const로 들어 올리는 것으로 충분합니까? 예: private const bool cacheReturnValues = true 다음 if(cacheReturnValues) /**/

그것은 약간의 일회용 댓글이었습니다. 인정합니다. 그래서 너무 많은 변경 없이는 실제로 가능했을지 모르겠습니다. 그러나 내가 의미한 바는 이랬습니다.

@andreasnilsen 은 지금 동작을 변경하고 싶지만 이것이 주요 변경 사항이 만들면 @andreasnilsen 에게 지금 동작을 변경할 수 있는 방법을 제공하고 다른 클라이언트는 중단하지 않습니다.

AutoFixture 4를 도입할 때 기본 구성을 변경하여 기본 동작이 반환 값이 캐시되지 않도록 합니다. 아니면 단순히 해당 옵션을 제거할 수도 있습니다...

부울 cacheReturnValues 와 같은 것이 이를 수행하는 한 가지 방법일 수 있지만 클라이언트가 값을 변경할 수 있도록 해야 하므로 private 될 수 없습니다.

(우리는 정확히 두 개의 값이있을 거라는 확신 아니라면 또한, 우리는 고려해야 enum 대신의 bool .)

아, 처음에는 v4에서 발견하고 변경하기 쉬운 내부 플래그를 의미한다고 생각했습니다.

마음에 오는 처음 두 가지 접근 방식은 다음과 같습니다.

• AutoConfiguredMoqCustomization 의 생성자에 부울 매개변수(이전 버전과의 호환성을 위해 선택사항)를 추가하기 MockVirtualMethodsCommand 하면 MockType.ReturnsUsingContext 로 전파됩니다. 이것은 보인다:
  
  
  
  1. 약간 복잡하고
  
  
  2. 너무 _임시_. 사용자 정의에 더 많은 구성 매개변수를 추가하려는 경우 생성자가 너무 복잡해지고 사용/유지보수가 어려워집니다.
  
  
• 위의 (ii) 문제를 해결하려면 매개변수 개체 패턴 을 사용하십시오.

나는 우리가 후회하고 나중에 고착될 수 있는 디자인 결정을 내리는 것을 경계하므로 이 프로젝트를 유지하는 귀하의 전문 지식/경험을 높이 평가할 것입니다.

전략 같은 걸 생각하고 있었는데...

아 물론이죠! "구성 값"에 집착하고 한 걸음 물러나는 것을 잊은 것 같습니다.

답변이 늦어서 죄송합니다. 정신이 멍해졌습니다. 곧 살펴보고 디자인 제안서로 돌아오겠습니다.

최근에 우리는 사용자 정의 조정을 위한 속성을 사용하기 위해 사용자 정의 리팩토링을 수행했습니다. 잠재적으로 이 기능은 다음과 같이 제어될 수 있습니다(더 나은 설정 이름 찾기).
c# new AutoMoqCustomization { CacheCallResults = false }

내부적으로는 위에서 조언한 것과 같은 다른 전략을 통해 이를 구현할 수 있습니다.

이를 구현하는 것이 비교적 간단해야 하므로 태그에서 점프로 표시합니다.

@zvirja 가 저를 조금 도와 있나요? 그리고 제가 이 문제를 해결할 수 있습니다. 어디서부터 시작해야할지 모르겠습니다 :)

@micheleissa 관심 감사합니다! AutoMoq 소스 코드를 읽고 내부 메커니즘을 이해하기 위해 디버깅하는 것이 좋습니다. 아주 작아서 시간이 많이 걸리지는 않을텐데...

더 구체적인 질문이 있으면 질문하십시오 😉