Más de Silverlight Unit Testing - Asynchronous Tests

Ya había mencionado un post a la introducción de Jeff Wilcox a la herramienta escrita por el mismo y la actualización a SL Beta 2 y los templates tanto de proyecto como para las Clases de Prueba. Después de usarlo me he topado con varios know issues, que esperamos se arreglen para cuando liberen Silverlight 2.0, pero ningún showstopper. Todo correo muy bien y las pruebas hechas con TFS, escritas para los objetos de negocio o para WPF son fáciles de migrar.

Dada la frecuencia en que tenemos tareas Asincronas en SL, necesitamos también soporte para poder probar estas. Un ejemplo tipíco es un WebRequest. En este caso lo veremos para un Servicio Web para el cual ya previamente agregamos la referencia. Este es el code snippet que les servirá para darse una idea de como crear este tipo de pruebas.

[TestClass]
public class ServiceClientTest:SilverlightTest{
   [TestMethod]
   [Asynchronous]
   public void GetTest()
   {
      ServiceClient client = new ServiceClient();
      client.GetCompleted += client_GetCompleted;
      client.GetAsync();
   }

   void client_GetCompleted(object sender, GetCompletedEventArgs e)
   {
      // Do something with e.Result;
      // Call this when done
      this.TestComplete();
   }
}

Decoramos con TestClass y TestMethod como en todas nuestras pruebas, pero agregamos el atributo Asynchronous a nuestro TestMethod. Esto hará que el framework se quede esperando a que otros threads terminen su chamba. Así que no tendremos que detener nuestro TestMethod y esperar a que nuestro webService obtenga una respuesta y lidiar con la sincronización. En algún momento se deberá mandar llamar a nuestro metodo client_GetCompleted y ahí haremos los asserts necesarios con el resultado. Al final, para indicarle al Testing Harness que ya terminamos debemos de llamar el metodo TestComplete. Si no hacemos esto, nuestra prueba se colgara. En caso de que exista alguna excepción y nuestro handler nunca se mande llamar, el framework se dará cuenta y marcará la prueba como fallada. Justo como se espera, funciona bien y es realmente simple.

Espero y les resulte útil.

Algo adicional que quisieran tomar en cuenta es que si van a mandar llamar a un WS desde SL tendrán problemas por Cross Domain Calls. Por más que configuren su servidor correctamente con el ClienteAccessPolicy.xml correcto va a fallar ya que por default las pruebas corren directamente sobre un archivo y no sobre un WebSite. Lo recomendable es en su website agregar una referencia a su proyecto de pruebas para que corran en el mismo contexto o al menos dentro de un WebServer de tal forma que pueda hacer Cross Domain Calls.