domingo, 9 de agosto de 2009

Flex Unit 4

Recientemente salió al aire Flex Unit 4 (versión Beta en este momento). Esta versión incorpora muchas mejoras, incluyendo mucha funcionalidad incorporada de la libreria para pruebas Fluint, quien le dono muchas mejoras a la misma, sobre todo en el manejo asincronomo.
Debemos recordar que en Flex/Flash estamos dentro de un ambiente asincronimo, esto es: hacemos el llamado a una función pero no sabemos cuando se hara devolvera el llamado a la función. Esto ya que el Flash Player no soporta multi hilos y al hacer uso de ciertos recursos que no tenemos en realidad una idea clara de cuanto va a durar en responder (llamado al servidor, cargar una pelicula, etc) puede hacer que la aplicación termine pegandose y la experiencia de usuario sea demasiado desagradable.
Una de las nuevas caracteristicas incorporadas en esta versión es el uso de metadatas. Esta es una caracteristica utilizada en Flex sobre todo cuando marcamos una propiedad como [Bindable]. Mucha gente no esta al tanto que en Actionscript 3 uno puede crear sus propias metadatas y utilizarlas como quieran dentro de su aplicación, lo cual a mi gusto es demasiado elegante.
Otra nueva caracteristica es que ya no se hace uso de la herencia (para crear nuevos tests y suites), ahora se usan metodos estaticos al estar utilizando metadatas. Ademas podemos ejecutar nuestros tests con distintos Runners (Flex Unit, Fluint, air, etc) que nos brindaran distintas caracteristicas de acuerdo a nuestras necesidades.
A continuacion unos pocos ejemplos de algunos principios. Espero poder agregar mas con el tiempo.

Creación de Suites:
Los suites son un conjunto de tests. Podemos tener dentro de un suite multiples tests.

package tests
{
[Suite]
[RunWith("org.flexunit.runners.Suite")]
public class DelegatesTestSuite
{
//Tests se declaran como propiedades
public var test1:MiClaseTest;
}
}

Creando un Test con un delegate:

package tests
{
public class MiClaseTest
{
//Metodo asincronomo:
//Marcamos el metodo como test y lo colocamos como primero
//en la lista. Ademas le decimos que espere al menos 3500 ms
//para que nos devuelvan algun valor
[Test (async, timeout="3500",order=1)]
public function loginUser():void
{
var user:User = new User()
user.username = "user2";
user.password = "123xyz";

var delegate:UserDelegate = new UserDelegate();
var responder:IResponder = Async.asyncResponder(this, new
TestResponder(onLoginUserComplete, onLoginUserFault), 3000);
}

//Este es el handler que recibira elresultado del
//servidor.
//@param event ResultEvent del servidor.
//@param token, es el objeto inicial que pasamos en el llamado
private function onLoginUserComplete(event:Object, token:Object):void
{
Assert.assertTrue(event.result.authenticated);
}

private function onInsertUserFail(event:FaultEvent, token:Object):void
{
Assert.fail('Error loading user: ' + event.fault);
}
}
}

Creando Teorias:

Y que es esto? Es un nuevo concepto (al menos en el mundo de testing en Flex) Lo que nos dice es que si creemos que algo va a ejecutarse correctamente, tiene que ejecutarse correctamente con cualquier informacion que le sea pasada como parametro, por ejemplo, si debo encontrar que el valor absoluto de un numero va a ser siempre positivo, la teoria me dice que cualquier numero que le pase, va a ser mayor a 0. Entonces en mi test puedo poner un numero infinto de numeros a probar, solo que nosotros no tenemos tanto tiempo como para eso, entonces escogemos un conjunto finito de valores a probar y con ese conjunto validamos nuestra teoria.

Primero tengo que marcar la clase como que tiene una teoria, para que pueda ser procesada con el metadata [RunWith]

package tests
{
[RunWith("org.flexunit.experimental.theories.Theories")]
public class MiClaseTest
{
...
Creando un sets de datos para probar:
Ocupo 2 metadatas [ArrayElementType] utilizado en mxml para especificar el tipo de dato dentro de una coleccion y el metadata [DataPoints] que marca nuestros set como un conjunto para probar.

[DataPoints]
[ArrayElementType("Object")]
public static var usuariosValidos:Array = [
{username:"user1",password:"123xyz"},
{username:"user2",password:"344112"},
{username:"user3",password:"o5ii33"}
];
Creacion de un test con teoria:
Marcamos el metodo conel metadata [Test] y el metadata [Theroy]
[Theory]

[Test(async,timeout="10000")]
public function validUsers(usuarios:Object):void
{
var delegate:UserDelegate = new UserDelegate();
var responder:IResponder = Async.asyncResponder(this, new
TestResponder(onUserLoginComplete, onUserLoginFail), 2500);

delegate.authUser(usuarios.username, usuarios.password);
}

Esto hace que el test se ejecute la cantidad de datos que tengamos dentro de nuestro datapoint, en este caso se ejecutara automaicamente 3 veces.
Esto verdaderamente facilitara nuestro desarrollo en pruebas y nos permitira asegurarnos que podamos testear mejor nuestra aplicacion con menor esfuerzo

Otros Recursos
Introduccion (mejor link que he visto)
Excelente Tutorial
Pruebas Integracion
Importancia Pruebas y Feedback

Integrando aplicaciones y sobreviviendo a ello

- "Ya está listo! Dalé probá!!"
- Mmmmm... no amigo, no funciona!
- "Es en serio?? Si yo lo probé!"
- Si... pero no funciona! Te voy a enviar el log con el error para que lo revises.
- "Ok mandalo! Solo que voy saliendo, pero lo veo mañana a primera hora..."











Photo By Zach Klein


Y así termina otro día para el programador de front end, donde no pudo avanzar todo lo que quería y donde tendrá que atrasarse unas horas mas para poder terminar sus tareas.

Esta es una historia repetida diariamente para muchos programadores de clientes para internet, donde sus aplicaciones son apenas la interfaz de acceso para sus usuarios a servicios con bases de datos, servicios externos y demas aplicaciones que pueda tener un sitio corporativo.

Hablando con mi colega y amigo Ivan Alvarez - quien trabaja en la Bolsa Nacional de Valores en Mexico desarrollando aplicaciones financieras de ultima tecnología con Adobe Flex y Java en el lado del servidor - nos dimos cuenta que nuestros trabajos aunque son en areas totalmente distintas (yo trabajo para Scrapblog un sitio en Flex para crear tarjetas y manualidades digitales) enfrentamos estas mismas situaciones aunque estemos a miles de millas de distancia, con gente completamente distinta.


Photo by: http://www.lumaxart.com/

La integración de aplicaciones con clientes en Flex y código de servidor se puede convertir muchas veces en una tarea titánica y dolorosa. Sin embargo estamos convencidos que no debe ser así:
  • Existen distintas formas para comunicarse: Webservices, Rest Services y Remote Objects.
  • Los tres metodos son robustos, probados y comprobados.
  • Para Remote Objects, existe un protocolo de comunicacion (para la serializacion y deserializacion de la informacion) definido por Adobe que es AMF3. Este protocolo es bastante rapido, comprimido y binario lo cual hace que la informacion se transmita mas rapido.
  • Este protocolo ha sido implementado multiples veces para distintas plataformas, empezando con Java (BlazeDS, LifeCycle Data Services, Weborb, GraniteDS), .Net (Weborb, FluorineFx), Rails (Weborb, RubyAMF), PHP(Weborb, AMFPHP), entre otras. Esto quiere decir que puedes hacer tu backend en el lenguaje que quieras y utilizar esta implementación de AMF para comunicar tu aplicación Flex con el servidor de manera rapida, robusta y segura.
Con estos antecedentes, podemos decir que crear aplicaciones en Flex conectada a un servidor de aplicaciones con bases de datos o cualquier servicio que se ocupe es bastante sencillo. Sin embargo el problema que mas sufrimos es cuando tratamos de comunicarnos con los servicios expuestos por nuestro servidor. Generalmente hemos visto los siguientes problemas:
  • Los servicios no estan correctamente configurados y por lo tanto es imposible a nuestras aplicaciones accesarlos.
  • El nombre de los métodos no son los mismos que como se definió previamente (si es que tiene la suerte que le definan los nombres de sus servicios en algún lugar como un Wiki, email o un documento más oficial.
  • La signatura de los métodos no es la misma que la que esta documentada (error muy parecido al anterior)
  • El servicio no fue probado y sus métodos tiran excepciones cuando son llamados. Este es el mas común. Parece que nuestros amigos de backend nunca prueban, ya sea por Unit Testing o al menos ejecutar desde un cliente la invocacion al método. Esto tan simple, puede ayudarlos a ellos a darse cuenta mas tempranamente que hay errores y arreglarlos antes de decirnos que ya esta listos nuestros servicios.
  • Problemas de serialización al enviar la información. Debemos recordar que hay una capa intermedia entre nuestra aplicacion cliente y nuestro servidor. Ese se va a encargar de convertir nuestra informacion y datos en terminos que nuestra contra parte pueda entender. Por ejemplo algunas implementaciones del AMF3 tienen problemas a la hora de serializar fechas (zonas de horario, 24 horas vrs 12 -AM/PM, etc), otras problemas a la hora de serializar numeros, las enumeraciones por ejemplo son estructuras que no todas las implementaciones soportan. Este tipo de problemas hacen que la integración sea mas lentas, es un constante hacer/probar/repetir.
Ahora, todo esto presentado anteriormente no quieredecir que no hay manera de solucionar esta situación:

  • Documentacion de los servicios, métodos, parametros, valores de retorno,excepciones, etc. No tiene que ser una documentacion de 3 paginas por servicio. Lo minimo debe incluir eso que puse arriba. Muchos desarrolladores sienten pereza de hacer esta documentacion y ahi es donde empiezan los problemas.
  • Uso de unidades de prueba (o algún tipo de prueba) en el código del servidor que sea ejecutado antes de "entregar" el código.
  • Como dije anteriormente, existe una capa intermedia entre nuestro cliente y el servidor y ocupamos probar que esa capa funciona correctamente, por eso es bueno probar nuestros clientes y los respectivos llamados al servidor con utilidades como Flex Unit 4, Fluint, etc. Incluso algunas herramientas para llamados remotos (como Weborb) incluyen consolas para probar directamente estos servicios desde un ambiente creado en Flex.
  • Investigar la herramienta que utilizamos y conocer cuales son problemas conocidos en las mismas. Investigar más del proceso de serialización esto nos ayudara a reconocer posibles problemas tempranamente.
  • Aprender un poco como es el desarrollo en el lado del servidor. Si tienes ese conocimiento vas a tener un valor agregado en el mercado y ademas vas a conocer más del proceso y poder ayudar a detectar errores, sugerir formas de implementación, etc.
  • Enseñar. Si tienes estos conocimientos de arriba, enseñar a otros desarrolladores sobre todo esto. Iniciar la chispa en ellos para que investiguen igual. Esto debe ser de conocimiento para la mayoría de personas en el proyecto.
  • Cruzar los dedos y esperar que todo salga bien... :-P

Saludos!

Posts Relacionados

Integracion de Aplicaciones
Pruebas de Integracion
Llamadas Asincronimas
Interaccion con sistemas remotos