Flex, FlexUnit: Cómo probar que un evento se distribuye dos veces?

Question

Estoy probando un código de despacho evento en una aplicación Flex, utilizando el método de addAsync FlexUnit para las pruebas de que los eventos se envían. Muy bien hasta ahora, puedo asegurar que por lo menos un evento fue despedido. Sin embargo, quiero ser un poco más detallada; Quiero asegurar que exactamente el conjunto de eventos que estoy esperando sean expedidos. ¿Hay un patrón de prueba útil (o, incluso, marco de ensayo diferente - Soy flexible)? Para lograr esto

He intentado este código, pero no parece quedar invocado la segunda vez:

protected function expectResultPropertyChange(event: Event, numberOfEvents: int = 1): void {
    trace("Got event " + event + " on " + event.target + " with " + numberOfEvents + " traces left...");
    assertTrue(event.type == ResponseChangedEvent.RESPONSE_CHANGED);
    if (numberOfEvents > 1) {
        event.target.addEventListener(ResponseChangedEvent.RESPONSE_CHANGED, addAsync(expectResultPropertyChange, 1000, numberOfEvents - 1));
    }
}

public function testSomething(): void {
    requiredQuestion.addEventListener(ResponseChangedEvent.RESPONSE_CHANGED, addAsync(expectResultPropertyChange, 1000, 2));
    requiredQuestion.responseSelected("1", true);
    requiredQuestion.responseSelected("2", true);
}

Answer 1

En respuesta al comentario ...

  

¿Qué pasa si el evento se distribuye   ¿directamente? responseSelected no lo hace   activar un evento asíncrono en una   objeto compuesto, simplemente se envió   el evento en sí RESPONSE_CHANGED   directamente. No estoy viendo cómo este   enfoque puede ser burlado la utilización de su   método. Eso sí, estoy difusa en el   la práctica de pruebas simulacro en que está, así que estoy   Probablemente falta una solución simple   aquí.

.. en ese caso no es necesario utilizar una maqueta o addAsync. Algo como esto va a hacer:

public function testSomething(): void 
{
    var requiredQuestion : RequiredQuestion = new RequiredQuestion();

    var callCount : int = 0;
    requiredQuestion.addEventListener(ResponseChangedEvent.RESPONSE_CHANGED, function(event : ResponseChangedEvent)
    {
        callCount++;
    });

    requiredQuestion.responseSelected("1", true);
    requiredQuestion.responseSelected("2", true);

    assertEquals(2, callCount);
}

Answer 2

Esto va a ser un ejemplo de alto nivel de cómo un problema similar podría resolverse mediante un objeto burlado de lo que sea que está haciendo la llamada asincrónica. Obviamente no puedo ver su código, así que no te puedo dar un ejemplo preciso.

Así que, como ya he dicho en el comentario, puede burlarse de una dependencia en una clase de llamadas asíncronas falsos para que se conviertan síncrona. Tomar la clase de abajo

public class RequiredQuestion extends EventDispatcher
{
    private var someAsynchronousObject : IAsynchronousObject;

    public function RequiredQuestion(someAsynchronousObject : IAsynchronousObject = null)
    {
        someAsynchronousObject = someAsynchronousObject || new AsynchronousObject();
        someAsynchronousObject.addEventListener(Event.COMPLETE, asyncCallComplete);
    }

    public function responseSelected(id : String, flag : Boolean) : void
    {
        //Will asynchronously fire the Event.COMPLETE event
        someAsynchronousObject.startAsynchrounsCall(); 
    }

    protected function asyncCallComplete(event : Event) : void
    {
        dispatchEvent(new ResponseChangedEvent(ResponseChangedEvent.RESPONSE_CHANGED));
    }
}

Así que por defecto está utilizando la clase concreta que desea utilizar a menos someAsynchronousObjec se inyecta en la clase a través de la constructora. AsycnhronousObject probablemente tiene sus propias pruebas de unidad o está en una clase externa por lo que realmente no quiere o necesita estar probando su funcionalidad. Lo que ahora se puede hacer es crear un objeto de burla que implementa IAsynchronousObject que puede ser utilizado para simular su comportamiento. Utilizando el marco ASMock la prueba podría ser algo como esto:

public function testSomething(): void 
{
    var mockIAsycnhronousObject :  IAsynchronousObject =
        IAsynchronousObject(mockRepository.createStrict( IAsynchronousObject));

    SetupResult.forEventDispatcher(mockIAsycnhronousObject);
    SetupResult.forCall(mockIAsycnhronousObject.startAsynchronousCall())
        .dispatchEvent(new Event(Event.COMPLETE)); // all calls to the startAsynchronousCall method and dispatch the complete event everytime it's called.

    mockRepository.replayAll();

    var requiredQuestion : RequiredQuestion = new RequiredQuestion(mockIAsycnhronousObject);

    var callCount : int = 0;
    requiredQuestion.addEventListener(ResponseChangedEvent.RESPONSE_CHANGED, function(event : ResponseChangedEvent)
    {
        callCount++;
    });

    requiredQuestion.responseSelected("1", true);
    requiredQuestion.responseSelected("2", true);

    assertEquals(2, callCount);

    mockRepository.verifyAll();
}

Este es sólo un ejemplo de cómo puede ayudarle a burlarse de las pruebas unitarias. Hay toda una gran cantidad de información que hay en burlarse aunque todavía es muy nuevo en ActionScript (publicado en diciembre). ASMock se basa en el .NET burla de Rhino por lo que buscar burla de Rhino debe vomita mucho más resultados si necesita ayuda.

Sin duda, una forma diferente de pensar pero una vez que en ella se tiende a preguntarse cómo se metió por en la unidad de pruebas sin ellos.