구체적인 객체 대신 스텁을 매개 변수로 사용

Question

스텁을 만들고 매개 변수로 메서드에 전달해야합니다. 아무 문제없이 메서드에 전달되는 객체를 인스턴스화 할 수 있습니다.

ex. 아래에서이 메서드를 테스트하려면 TargetDataRanger 개체를 매개 변수로 사용합니다.) 그것을 스텁하고 b.에 전달해야합니다.) 종속성을 깨고 인터페이스 뒤에 놓은 다음이를 스텁하고 C에서 전달합니다.) 인스턴스화하고 메서드로 구체 객체로 전달합니다.

이 경우 아래의 구체적인 개체를 사용하여 도망 갈 수 있지만 그 것이 현명하고 일부 테스트 규칙 또는 그 밖의 것이 어떨까요?

public virtual Dictionary<DateTime, DateTime> ResolveDates(ISeries comparisonSeries, TargetDateRanger sourceRanger) 
    { 
     Dictionary<DateTime, DateTime> dates = new Dictionary<DateTime, DateTime>(); 

     foreach (DateTime keyDate in sourceRanger.ValidDates) 
      dates.Add(keyDate, this.ResolveDate(comparisonSeries, keyDate)); 

     return dates; 
    } 

Answer 1

기본 매개 변수를 사용할 수 있습니다.

void print(int a, string b = "default") 
{ 
    Console.WriteLine(a + b); 
} 

Answer 2

단위 테스트에서 독립형으로 테스트합니다. 나는 그것을 분해하고, 변수를 펌프 할 수있는 드라이버를 설정하고, 예상 결과를 볼 수 있도록 스텁을 가져야한다. 나는 그것이 나를위한 더 나은 테스트 철학이라고 느낀다. 그러나 나는 프로그래밍에 비교적 익숙하지 않다. 그래서 나는 나를 시험하는이 방법이 나에게 많은 것을 동시에 가르친다는 것을 알았다.

일단 완료되면 더 큰 시스템에이를 통합하고 새 드라이버 및 스텁 출력으로 다시 테스트 한 다음 전체 흐름이 작동하는지 확인하십시오.

구체적인 방법을 사용하여 본질적으로 뭔가 잘못되었다고 말할 수는 없지만 특히 작은 프로그램의 작은 조각 인 경우에는 그렇습니다.

Answer 3

이 방법에 대한 단위 테스트를 작성하는 경우 외부 종속성을 격리하거나 가짜로 만드는 것이 좋습니다. 문제는, 예를 들어 누군가가 ValidateDates 메소드를 변경 한 경우, 잘못된 이유로 테스트가 실패 할 수 있다는 것입니다. 다른 한편에서는 ValidateDates 메서드 내부에 무엇이 있는지 테스트하고 있습니다. 이것은 당신이 아마 여러 가지 것을 시험하기를 원한다는 것을 의미합니다. 또한 이것은 시험에 대한 좋은/구체적인 이름을 부여하지 못하게 할 수도 있습니다.

단위 테스트 ValidateDates 메서드를 개별적으로/별도로 수행 할 수 있습니다.

격리에서 논리/동작의 작은 부분을 테스트하는 것만 큼 종속성을 손상시키는 것이 중요합니다. 이렇게하면 Unit Tests IMO의 진정한 가치를 얻을 수 있습니다.

Answer 4

대답은 TargetDateRanger.ValidDates에 의존한다고 생각합니다. 단위 테스트에서 반환되는 속성을 완전히 제어 할 수 있다고 가정 할 경우 별도로 조롱 할 이유가 없습니다. 그것이 데이터베이스를 치고, 내부 논리를 가지고 있다면, DateTime.Now, 등등에 달려있다. 그런 다음 그것을 조롱 할 필요가있다.

기본적으로 단위 테스트의 "환경"을 완전히 통제하여 예측 가능한 결과를 얻고 실패한 코드를 신속하게 찾아 낼 수 있습니다. ValidDates이 잘못된 결과를 반환 할 가능성이있는 경우 별도로 단위 테스트를하고이 경우 모의합니다 ("불량 결과"로 인해 ResolveDates 메소드가 실패하지 않도록). 문제가 상주하지 않기 때문에 그곳에).