Silverlight에서 이벤트 트리거 대기 단위 테스트

Question

Silverlight 단위 테스트 프레임 워크를 사용하여 일부 View Manager 클래스를 테스트하고 있습니다. 일부 테스트에서는 PropertyChanged 이벤트가 발생해야합니다. 나는 현재 EnqueueConditional 및 WaitHandles의 조합

예제이 작동 한

[TestMethod] 
[Asynchronous] 
[Timeout(1000)] 
public void TestNotificationExample() 
{ 
    var manager = new UserManager(); 

    var waitHandle = new ManualResetEvent(false); 
    manager.PropertyChanged += (sender, propChangArgs) => 
           { 
            waitHandler.Set(); 
           }; 
    manager.DoTheThingThatTriggersNotification(); 
    // The notification event fires aynshronously to this 
    EnqueueConditional (() => waitHandler.WaitOne(0)); 
    // Enqueue other tests here.... 
    EnqueueTestComplete(); 
} 

을 사용하고

. 하지만 저에게 잔소리하는 질문이 있습니다.

실제로 WaitHandle을 사용해야합니까? 내가 방금 bool을 사용했다면 똑같이 수행 할 수 있을까요?

예 2

bool fHasFiredEvent = false; 
manager.PropertyChanged += (sender, propChangeArgs) => 
          { 
           fHasFiredEvent = true; 
          } 
manager.DoTheThingThatTriggersNotification();  
EnqueueConditional (() => fHasFiredEvent); 
EnqueueTestComplete(); 

아니면이 WaitHandle이 유지하지만, TimeoutAttribute을 잃고 대기에 시간 초과하면 좋을까요?

예 3

[TestMethod] 
[Asynchronous] 
public void TestNotificationExample() 
{ 
    var manager = new UserManager(); 

    var waitHandle = new ManualResetEvent(false); 
    manager.PropertyChanged += (sender, propChangArgs) => 
           { 
            waitHandler.Set(); 
           }; 
    manager.DoTheThingThatTriggersNotification(); 
    EnqueueCallback (() => Assert.IsTrue(waitHandler.WaitOne(1000)); 
    EnqueueTestComplete(); 
} 

그래서 지금은 세 가지 예를 서면으로 작성했습니다, 그들은 모두 작동합니다. 그래서 내 마지막 질문은

• 입니다. 어느 것이 가장 좋은 성능입니까? (비록 의 차이가 무시할 만하다고해도 그것은 순수하게 학문적으로 야다 야다 야다.)
• 근본적인 결함이 있습니까?

Answer 1

실제로 세 가지 예제에서 실제 코드를 실행하지 않으면 권위있는 대답을 줄 수는 없지만 # 2를 사용하고 # 1과 # 3을 명확하게 처리하는 것이 좋습니다.

저는 Jeff Wilcox의 Silverlight 유닛 테스트 프레임 워크의 소스를 훑어 보았습니다. 그리고 기억 하듯이, 그는 EnqueueConditional에 영리하면서도 끔찍한 해킹을 사용합니다. 즉, EnqueueConditional()에 전달 된 조건부를 반복적으로 호출합니다. 타이머/백그라운드 스레드. 매번 true를 반환하는지 확인합니다. (프로덕션 코드에서 원하는 것은 아니지만 테스트 프레임 워크의 경우 로직이라고 생각하면 충분합니다.)

테스트를 완료하는 데 몇 초가 걸리는 경우 waitHandler.WaitOne() (a) 여러 번 호출되고, 진행되는 동안 각 스레드를 차단합니다. 또는 (b) 다른 일을하기로되어있는 스레드를 막는 것. WaitOne()이 중요한 항목을 차단하지 않고 한 번만 호출된다는 점에서 운이 좋을 수도 있습니다. 하지만 확실히 # 2는이 테스트 프레임 워크를 사용하는 "표준"방법이며, WaitHandle의 더 복잡한 논리를 소개 할 구체적인 이유가 없다면 테스트 프레임 워크를 그 방향으로 밀어 넣으려고하지는 않을 것입니다.

말하자면, 누군가가 주위를 둘러보고 더 권위있는 답변을 전달하고자한다면, 나는 모든 귀가 다 :-).