Асинхронный тест FlexUnit4 - использование asyncHandler не ясно - PullRequest
Новая
       38

Асинхронный тест FlexUnit4 - использование asyncHandler не ясно

2 голосов
/ 24 июля 2010

Существует страница документа об асинхронном подходе FlexUnit4: http://docs.flexunit.org/index.php?title=Writing_an_AsyncTest

Вот концепция, которая меня смущает: 

// timer is a Timer instance set to tick once with a delay of TIMER_TIME.

[Test(async)]
public function testAsync() : void {
      var asyncHandler:Function = Async.asyncHandler( this, handleTimerComplete, ASYNC_TIME, null, handleTimeout );
      timer.addEventListener(TimerEvent.TIMER_COMPLETE, asyncHandler, false, 0, true );
      timer.start();    
}

handleTimerComplete вызывается, когда завершается объект таймерапосле TIMER_TIME).Это происходит только тогда, когда TIMER_TIME

Это действительно не имеет смысла для меня.Я ожидал бы периодически вызывать тестовую функцию с ограничением по времени, и как только тест пройдет успешно, периодический вызов должен успешно завершиться.С другой стороны, я не уверен, где поставить действия (что я хочу проверить) и где поставить тесты (утверждает).

Есть ли более подробная документация или пример, поясняющий подход?

Спасибо!

Ответы [ 2 ]

0 голосов
/ 02 декабря 2012

Утверждение в основном делает это: 

function assertEquals( value:*, ...rest) : void {
    for each( var item:* in rest ) 
        if( item != value ) throw new Error("fail");
}

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

Среда модульного тестирования запускает каждый метод тестирования в блоке try/catch, и любые непредвиденные ошибки, вызванные утверждениями, приводят к сбою теста. Вот как другие тесты могут продолжать работать, и как вы получаете ваши сообщения и результаты, даже если что-то пошло не так.

Проблема в том, что: если вам нужно сделать асинхронные утверждения, то есть проверить значения переменных в более поздний момент времени, поведение тестовой среды становится намного более сложным. Каким-то образом все вызовы методов, которые происходят между концом основного метода тестирования и фактическим концом теста, также должны отслеживаться, объекты, которые были созданы в setUp(), должны продолжать существовать, и все ошибки должны по-прежнему перехватываться. - иначе, весь тестовый запуск зависнет, и вы получите множество ошибок «ссылка на нулевой объект».

Фреймворк, однако, не может знать, когда закончится текущий тест, если нет какого-либо способа сообщить о полноте - и по этой причине вы должны использовать хотя бы один asyncHandler (или failOnEvent / proceedOnEvent, если вам нужно только проверить, было ли событие отправлено / не отправлено вообще) для обработки события, отмечающего конец теста, т. е. в вашем случае, TimerEvent.TIMER_COMPLETE - или сбой, если это событие никогда не встречалось. В любом случае теперь можно запустить следующий тест.

Я считаю, что можно использовать несколько asyncHandlers в одном и том же тесте, но я не уверен, что asyncHandler будет работать правильно, если вызывается несколько раз в цикле - это как-то противоречит функциональности тайм-аута.

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

Кстати, если вам интересно, как работает остальная часть FlexUnit, вы можете найти полный исходный код на GitHub .

0 голосов
/ 02 декабря 2012

я только начинаю использовать asyncHandlers, и я придерживался подхода, согласно которому, если ваша функция handleTimerComplete запускается, то в этой функции вы можете добавить свой проход assert, в то время как вы утверждаете неудачу.

для меня это http события, поэтому в моем обработчике "pass" я также могу использовать assert для проверки правильности кода состояния и т. Д.

Одна вещь, которую я пытаюсь выяснить, это если вы можете повторно использовать тот же самый асинхронный обработчик, например связать его в качестве прослушивателя для 3 или 4 различных типов событий, так что я думаю, что нет, кажется, что во второй раз, когда он вызывается, вы получаете ошибку, что указатель на функцию обработчика теперь равен нулю. нужно провести еще какое-то расследование, хотя

...