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

Question

Существует док страница о асинхронном подходе 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 < ASYNC_TIME. handleTimeout вызывается, если asyncHandler завершен (после ASYNC_TIME). Это происходит, если ASYNC_TIME < TIMER_TIME.

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

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

Спасибо!

Answer 1

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

для меня его HTTP события так в моем «проходят» обработчик я также использовать Assert для проверки правильности кода состояния и т.д.

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

Answer 2

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

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 за тест - и поместить все другие утверждения в «обычные» методы обработчика событий.

btw, если вас интересует, как работает остальная часть FlexUnit, вы можете найти full source code at GitHub.