Как TDD асинхронные события?

Question

Основной вопрос заключается в том, как создать единичный тест, которому необходимо вызвать метод, дождаться события, которое произойдет в тестируемом классе, а затем вызвать другой метод (тот, который мы действительно хотим проверить)?

Вот сценарий, если у вас есть время, чтобы прочитать дальше:

Я разрабатываю приложение, которое должно контролировать часть оборудования. Чтобы избежать зависимости от доступности оборудования, когда я создаю свой объект, я указываю, что мы работаем в тестовом режиме. Когда это происходит, тестируемый класс создает соответствующую иерархию драйверов (в данном случае тонкий макет уровня драйверов оборудования).

Представьте, что класс, о котором идет речь, является Лифт, и я хочу проверить метод, который дает мне номер пола, который находится на лифте. Вот как мой фиктивный тест выглядит как прямо сейчас:

[TestMethod] 
public void TestGetCurrentFloor() 
{ 
    var elevator = new Elevator(Elevator.Environment.Offline); 
    elevator.ElevatorArrivedOnFloor += TestElevatorArrived; 

    elevator.GoToFloor(5); 

    //Here's where I'm getting lost... I could block 
    //until TestElevatorArrived gives me a signal, but 
    //I'm not sure it's the best way 

    int floor = elevator.GetCurrentFloor(); 

    Assert.AreEqual(floor, 5); 
} 

Edit:

Спасибо за все ответы. Вот как я это сделал:

[TestMethod] 
    public void TestGetCurrentFloor() 
    { 
     var elevator = new Elevator(Elevator.Environment.Offline); 
     elevator.ElevatorArrivedOnFloor += (s, e) => { Monitor.Pulse(this); }; 

     lock (this) 
     { 
      elevator.GoToFloor(5); 

      if (!Monitor.Wait(this, Timeout)) 
       Assert.Fail("Elevator did not reach destination in time"); 

      int floor = elevator.GetCurrentFloor(); 

      Assert.AreEqual(floor, 5); 
     } 
    } 

Answer 1

Я думаю, что вы уже на правильных линиях. Тест должен ждать, пока произойдет какое-либо событие, или вы судите о том, что он слишком долго прибыл и должен отказаться от ожидания.

Для этого вы можете использовать Monitor.Wait с тайм-аутом в своем тесте и сигнализировать его с помощью Monitor.Pulse при поступлении события.

 

[TestMethod] 
public void TestGetCurrentFloor() 
{ 
    var elevator = new Elevator(Elevator.Environment.Offline); 
    elevator.ElevatorArrivedOnFloor += TestElevatorArrived; 

    lock (this) 
    { 
     elevator.GoToFloor(5); // NOTE: this must hand off to a second thread, and the ElevatorArrivedOnFloor must be raised by this other thread otherwise the Monitor will be pulse before we've started waiting for it 

     if (!Monitor.Wait(this, TIMEOUT)) Assert.Fail("Event did not arrive in time."); 
    } 

    int floor = elevator.GetCurrentFloor(); 

    Assert.AreEqual(floor, 5); 
} 

private void TestElevatorArrived(int floor) 
{ 
    lock (this) 
    { 
     Monitor.Pulse(this); 
    } 
} 
 

(Assert.Fail() вызов здесь должен быть заменен на любой механизм ваш инструмент модульного тестирования используется для явного проваливать испытание - или вы могли бы бросить исключение.)

Answer 2

Может быть, это просто плохой пример, но ваш лифт звучит скорее как машина состояний, чем то, что просто обрабатывается асинхронно.

Итак, ваш первый набор тестов может проверить, что GoToFloor() установит состояние в движение и правильное направление движения.

Тогда следующий набор тестов будет на TestElevatorArrived() и будет проверять, что если ваше состояние двигалось к определенному полу, то фактическое движение (т. Е. Функция, вызываемая после асинхронного ожидания, или обработчик для аппаратного запуска «перемещенного» события) будет установлено состояние на ожидаемый этаж.

В противном случае то, что вы тестируете, наиболее вероятно, что ваше издевательство над оборудованием правильно издевается над временем и движением, что не кажется правильным.

Answer 3

Это мой аналогичный подход.

[TestMethod] 
    public void TestGetCurrentFloor() 
    { 
     var completedSync = new ManualResetEvent(false); 
     var elevator = new Elevator(Elevator.Environment.Offline); 

     elevator.ElevatorArrivedOnFloor += delegate(object sender, EventArgs e) 
     { 
      completedSync.Set(); 
     }; 

     elevator.GoToFloor(5); 

     completedSync.WaitOne(SOME_TIMEOUT_VALUE); 

     int floor = elevator.GetCurrentFloor(); 

     Assert.AreEqual(floor, 5); 
    } 

Вы также можете проверить возвращаемое значение WaitOne() для проверки, что ваш обработчик событий был вызван.

Answer 4

Мне действительно не нравится состояние гонки с помощью метода Monitor.Pulse/Wait выше.

А, не столь хорошо, но эффективный способ будет что-то вроде следующего:

[TestMethod] 
public void TestGetCurrentFloor() 
{ 
    // NUnit has something very similar to this, I'm going from memory 
    this.TestCounter.reset(); 

    var elevator = new Elevator(Elevator.Environment.Offline); 
    elevator.ElevatorArrivedOnFloor += (s,e) => { Assert.That(e.floor).Is(5) } 

    elevator.GoToFloor(5); 

    // It should complete within 5 seconds.. 
    Thread.Sleep(1000 * 5); 
    Assert.That(elevator.GetCurrentFloor()).Is(5); 

    Assert.That(this.TestCounter.Count).Is(2); 
} 

Мне не нравится это решение, потому что если лифт приходит в течение 500мс, вы остаетесь в ожидании еще 4500ms. Если у вас было много таких тестов, и вы хотели, чтобы ваши тесты были быстрыми, я бы полностью избегал этого сценария. Однако этот тест также удваивается как проверка работоспособности/проверки работоспособности.

Хотите, чтобы лифт поднялся в течение 2 секунд? Изменение таймаута.