• El testing no sirve para nada
• Esto es bien simple, no necesita testing
• Que testén los usuarios
• El testing es una pérdida de tiempo
• Testear es improductivo
• Testear es aburrido

Bueno, déjenme decirles algo: todas estas afirmaciones están equivocadas. Sí, incluso la última. Testear tiene muchos beneficios, incluso tiene beneficios no directamente relacionados con el testing. Pero no nos adelantemos.

Tal vez la primera -El testing no sirve para nada- sea una de las más dichas y escuchadas. Esta frase la dice la gente que nunca testeó. No conozco a nadie con disciplina de testing que piense esto.

Otra frase nefasta es la tercera -Que testén los usuarios-. No hay peor cosa que entregarle al usuario que un software plagado de errores. La confianza del usuario es una de las cosas más importantes en un proyecto. Al usuario hay que tenerlo de nuestro lado ya que él/ella es la razón por la cual estamos haciendo ese sistema. La confianza se puede perder en un abrir y cerrar de ojos por un error que lleva 5 minutos eliminarlo. Y cuando sucede esto, volver a ganar la confianza cuesta mucho.

Pero ¿por qué se le tiene tanta idea al testing? y sobre todo por la gente que no tiene disciplina testeadora. Yo creo que es porque el testing nos expone a nuestros errores e inconscientemente tratamos de evitar esto. Y mientras haya errores, obviamente, la tarea no está terminada.

Cómo sería la implementación de una funcionalidad para un programador que no testea disciplinadamente:

1. Programación de la funcionalidad
2. Probar un par de veces (en el mejor de los casos)
3. Deploy

Para cualquier funcionalidad más o menos compleja, esto lleva a que haya un caso que no se consideró en el punto 2 y por lo tanto a un error en el sistema. Entonces:

1. Corregir el error
2. Probar un par de veces (ahora un poco mejor por el sentimiento de culpa
3. Deploy

Seis pasos, suponiendo que el error queda arreglado.

Como sería el mismo ciclo, pero con disciplina de test:

1. Programación de la funcionalidad
2. Programación del test de la funcionalidad
3. Probar la funcionalidad
4. Deploy

Cuatro pasos.

Les aseguro que la calidad del producto es mucho más alta y no quedamos pegados con el usuario. El “simple” hecho de programar el test, no hace pensar más. Y ¿tardamos más? Generalmente no, porque no hay que corregir errores ni volver a pasar a producción. Igualmente, sería preferible tardar más que por tratar de sacar el sistema antes, se escape un error se dañe la confianza del usuario.

Herramientas

Bueno, basta de psicología barata. Ahora voy a nombrar algunas herramientas que asisten al testing.

Simplemente voy a nombrarlas, hay mucha literatura en Internet sobre estas herramientas.

Unitarios

Para hacer tests unitarios hay básicamente dos frameworks JUnit y TestNG. El segundo es más abarcativo que el primero.

Integración

Para hacer tests de integración, también hay frameworks que nos facilitan la vida, jMock o Mockito por nombrar dos.

Cobertura

La cobertura de código es sin duda una de las herramientas más interesantes para tener una idea de la calidad de nuestro test. Con esta herramienta es muy fácil saber si se nos escaparon casos en nuestros tests, ya que van a aparecer lineas de código son cubrir. La idea es aproximarse lo más posible a 100%.

El hecho de testar, produce efectos secundario (positivos) en nuestro código:

1. Con el tiempo produce métodos más simples: Es más fácil testear métodos cortos y simples, que largos y complejos. Cuando programamos pensando en el testing esto surge naturalmente. El código simple es más fácil de mantener.
2. Los tests tienden a mejorar la modularización del sistema, ya que pueden exponer problemas de dependencias entre los módulos. Ej: dependencias circulares.
3. Los tests tiene un efecto psicológico en el desarrollador, dándole confianza en su producto y fomentando la motivación. Esto hace que testear sea “divertido”.

Notas finales

El test debe ser tomado con profesionalismo: la tarea no está terminada si no tiene el test correspondiente. Está de más decir que el test tiene que ser de alta calidad.

El test sirve para verificar y descubrir errores cuando estamos programando la funcionalidad, pero más importante aún, es que nos da la tranquilidad de que dentro de 6 meses cuando se realizaron un montón de cambios, nuestra funcionalidad se sigue comportando como esperamos.

Implantar el testing en un equipo no es tarea fácil. Requiere tiempo, esfuerzo y no bajar los brazos. Siempre hay rechazo a algo nuevo. Incluso la gente que reconoce el valor del testing, le cuesta arrancar a testear profesionalmente.

El testing (cómo cualquier otra cosa) no puede ser algo impuesto al equipo; por el contrario, tiene que ser aceptado por el equipo, haciéndole ver los beneficios del testing profesional en el día a día. Bien vale la pena el esfuerzo.

El “celular” de hoy en día es como una computadora con un montón de periféricos integrados: cámara, teclado, pantalla, teléfono celular, lector de memoria externa, wifi, gps, gsm, etc. Y todo esto en la palma de la mano.

Algunos de estos dispositivos móviles traen sistemas operativos propietarios, otros utilizan alguna versión de Windows, Linux o Symbian OS. Pero hay una características que la gran mayoría tienen en común: Java. Obviamente no es la versión de Java full power que se instala en nuestro desktop, laptop o servidor. Se trata de una versión adaptada a dispositivos móviles en los cuales no se cuenta con Gigas de RAM, o múltiples CPUs con frecuencias de reloj del orden de los Giga Hetrz.

Sorprendentemente, Java Micro Edition (JME, A.K.A. J2ME) tiene las características que la hacen una plataforma bien interesante para desarrollar aplicaciones y particularmente juegos. Y estos últimos son los que vamos a explorar.

Primero un poco de teoría

Dada la cantidad de dispositivos móviles -todos con características diferentes- se inventaron los “perfiles de capacidades”: MIDP por Mobile Information Device Profile. Dependiendo de la versión de MIDP, el dispositivo va a tener más o menos capacidades de: comunicación, presentación, audio, etc.

Además de MIDP, existe otra especificación llamada CLDC por Connected Limited Device Configuration, que define capacidades de bajo nivel del dispositivo, por ejemplo, si tiene la capacidad de manejar número con punto flotante.

MIDP se apoya en CLDC para formar la plataforma Java ME. La idea es desarrollar en la plataforma más compatible que se pueda. Hoy por hoy, la mayoría de los celulares soportan MIDP 2.0 y CLDC 1.1, pero si podemos restringirnos a CLDC 1.0 mejor. El Motorola V360 es un ejemplo de teléfono móvil con MIDP 2.0 y CLDC 1.0.

Entonces cuando empecemos a desarrollar, tenemos que elegir que versión de MIDP y CLDC vamos a utilizar. En la página de Oracle (http://java.sun.com/javame/technology/index.jsp), se puede encontrar más información y el SDK (http://java.sun.com/javame/downloads/index.jsp).

Bien, tenemos el SDK instalado, tenemos nuestra IDE de confianza configurada. ¿Y ahora qué? ¡A programar! Bueno, no tan rápido. ¿Cómo se programa un juego? Esto es algo que los que venimos haciendo IT desde ya hace años, no tenemos muy claro. En Internet hay mucha documentación, pero la realmente buena es escasa.

Primero que nada, veremos como es el esqueleto de un juego -en pseudocódigo-:

proceso entrada del usuario
actualizo el estado del juego
dibujo la pantalla
goto 1

Santo patrono de la informática, perdón por el goto.

No hay nada revelador en estas 4 lineas, pero lo que si se pueden empezar a ver algunos problemas. Por ejemplo: este juego va a ejecutar a distinta velocidad según de la potencia del celular. Algo claramente no deseable. Obviamente queremos que nuestro juego funcione a la misma velocidad en cualquier celular, sin importar la potencia del mismo.

Para esto, hacemos un pequeño cambio:

proceso entrada del usuario
actualizo el estado del juego
dibujo la pantalla
esperar X milisegundos
goto 1

Ahora variando X, podemos variar la velocidad del juego. Fácil… ¿no? Queda en manos del usuario elegir X mediante, por ejemplo, el menú el juego. Pero, ¿no se podría determinar X automáticamente? Mejor aún, ¿no se podría determinar X dinámicamente en cada vuelta del ciclo? Claro que sí. Ahora vemos como:

ciclos_por_segundo = 30
milisegundos_por_ciclo = 1000 / ciclos_por_segundo
t_inicial = ahora()
proceso entrada del usuario
actualizo el estado del juego
dibujo la pantalla
t_ciclo = ahora() - t_inicial
si (t_ciclo < milisegundos_por_ciclo) entonces
    esperar (milisegundos_por_ciclo - t_ciclo) milisegundos
goto 3

Nota: La función ahora() devuelve la hora actual en milisegundos, algo como lo que hace System.currentTimeMillis() en Java.

Lo que se hace es, tomar el tiempo que toma un ciclo completo (4, 5 y 6). Si ese tiempo es menor que la cantidad de tiempo que establecimos para cada ciclo en 1 y 2, entonces esperamos esa diferencia de tiempo. Así, todos los ciclos demoran lo mismo y el tiempo de espera se ajusta dinámicamente.

De esta forma logramos un rendimiento igual entre celulares de distinta potencia. Este método se puede mejorar implementando saltos de ciclos (frame skipping) cuando el celular es de muy baja potencia, pero corremos el riesgo de que el juego se vuelva injugable. Así, el juego ejecutará más lento en celulares de poca potencia, ya que todo el tiempo se consumirá en los puntos 4, 5 y 6 y nunca entrará en espera.

Es sorprendente la cantidad de cosas interesantes que se pueden hacer utilizando esta sencilla técnica.

A la práctica

Vamos a implementar, con esta técnica, el “hola mundo” de los juegos: el PONG de a uno.

Pong

Es como si fuera un Arkanoid, pero sin los ladrillos. Es verdad, no es muy divertido.

La implementación en Java del bucle principal sería algo así:

final int CICLOS_POR_SEGUNDO = 30;
final int MILISEGUNDOS_POR_CICLO = 1000 / CICLOS_POR_SEGUNDO;
while (true) {
    long tInicial = System.currentTimeMillis();
    procesarEntradaDelUsuario();
    actualizarEstadoDelJuego();
    dibujarLaPantalla();
    long tCiclo = System.currentTimeMillis() - tInicial;
    if (tCiclo < MILISEGUNDOS_POR_CICLO) {
        Thread.sleep(MILISEGUNDOS_POR_CICLO - tCiclo);
    }
}

Notar que hasta ahora no hay nada hecho particularmente para el PONG. Lo particular estará en las funciones procesarEntradaDelUsuario(), actualizarEstadoDelJuego() y dibujarLaPantalla().

La primera tiene la responsabilidad de tomar la entrada del usuario y modificar algo en el juego, en este caso sería la posición de la paleta. Sí, la paleta es ese rectángulo verde.. hay que tener imaginación

La segunda debe actualizar el estado interno del juego. En este juego, esta función tiene dos objetivos: a) mover la pelota y b) si la pelota se va hacia abajo, entonces el juego termina con el fatídico “Game Over”.

La tercer y última función, debe tomar el estado del juego y dibujarlo en la pantalla.

El código fuente se puede bajar desde acá: pong-scr.tar. En esta implementación, nunca se pierde. Cuando la pelota se va para abajo, aparece nuevamente en el medio de la pantalla. Un buen ejercicio, sería agregarle vidas, que aumente la velocidad de la pelota, darle aceleración a la paleta, mejorar los gráficos, agregarle ladrillitos, sonidos, powerups y ponerle un nombre marketinero (que no sea Arkanoid, claro ) y de ahí, a la fama!

Enjoy!

Este es el último artículo de esta serie. En este voy a presentar como se configura el servidor y además voy a subir el código fuente.

Estructura de directorios:

aquait-appserver/

• application/
  • db_connection_pool.config Configuración del módulo pool de conexiones a la base
  • modules.config Configuración de los módulos
  • services.config Configuración de los servicios
  • messaging.config Configuración del módulo de mensajería
  • security.config Configuración de seguridad
• lib/
  • aquaitrt-bin_2009r1.jar Runtime
  • mail.jar Servicio de mail
• log/
• logging.config Configuración de logging
• server.config Configuración del servidor
• start.sh
• stop.sh
• start.cmd      Scripts para iniciar y detener al servidor
• start.sh
• stop.cmd
• stop.sh

logging.config

handlers = java.util.logging.ConsoleHandler, java.util.logging.FileHandler

java.util.logging.FileHandler.level = ALL

java.util.logging.FileHandler.pattern = ./log/server.%u.txt

java.util.logging.FileHandler.limit = 50000

java.util.logging.FileHandler.count = 1

java.util.logging.FileHandler.formatter = com.aquait.utils.logging.ServerFormatter

java.util.logging.ConsoleHandler.level = INFO

java.util.logging.ConsoleHandler.formatter = com.aquait.utils.logging.ServerFormatter

Archivo que configura el logging. El servidor usa la API estándar de Java SE para logear. El archivo por defecto define dos handlers. El primero que genera archivos y el segundo logea a la consola. Por más detalles, ver http://java.sun.com/javase/6/docs/api/java/util/logging/package-summary.html.

server.config

# Server config

# Server listening port

#

port = 6666

# Worker pool size

#

workers.poolsize = 10

# Shutdown password

#

shutdown.password = _shut_down_now_server_

Este archivo define tres parámetros del servidor. Primero el puerto TCP/IP en el cual el servidor escucha conexiones. Los clientes se deberán conectar a este puerto. El segundo parámetro define la cantidad de workers (hilos) que atienden los pedidos de los clientes. Y el tercero es la contraseña para bajar el servidor. Se baja mediante el script stop que se comunica al puerto definido y manda un mensaje especial. El servidor solamente se puede bajar desde el mismo host en donde está ejecutando.

db_connection_pool.config

# DBConnectionPoolModule configuration

#

# Examples:

# url = jdbc:oracle:thin:@<host>:<port>:<database>

# driverclass = oracle.jdbc.driver.OracleDriver

#

enable = false

url = <url>

username = <user>

password = <pass>

driverclass = <driver_class>

autocommit = false

poolsize = 5

maxpoolsize = 10

Este archivo controla los parámetros del pool de conexiones a la base de datos.

modules.config

# Modules to load

# Format:

# module.name = <module_name>

# module[<module_name>].class = <module_class>

#

En este archivo se delcaran los módulos que van a desplegarse en el servidor. Cada módulo puede tener una cantidad varible de parámetros.

messaging.config

# MessagingModule configuration

#

enable = false

poolsize = 10

# Security realms

# Format (<n> starts at 0):

# security_realm[<n>] = <security_realm_class>

#

Este archivo configura la seguridad del servidor. Se pueden definir varios realms que se ejecutan en orden para cada pedido de los clientes.

services.config

# Services

# Format:

# service[<service_name>].interface = <service_interface>

# service[<service_name>].implementation = <service_implementation>

# service[<service_name>].parameter[<param_name>] = <param_value>

#

Este archivo configura los servicios que se publican en el servidor. Para cada servicio hay que configurar la interfaz y la implementación de esta. Además, opcionalmente, se pueden agregar parámetros de inicialización.

Con esto finalizamos esta serie. Siempre estoy a las orden ante cualquier consulta que tengan al respecto de este servidor.

Bajar código fuente: aquaitrt_2009-10-14.tar.gz

Siguiendo la exploración de los principales componentes de servidor, en este artículo vamos a ver el el componente de conexiones a la base de datos y el de mensajería. Los dos componentes se diseñaron e implementaron separadamente del servidor de aplicaciones, por lo que no están acoplados de ninguna forma. Para “agregarlos” al servidor, se implementaron módulos del servidor que los adaptan.

Pool de conexiones a la base de datos

El pool implementado es muy sencillo. Tiene una colección de conexiones con un tamaño inicial (configurable) y en caso de que el cliente (en este caso el servidor de aplicaciones) necesite más, crea hasta un máximo (también configurable).

Diseño del pool de conexiónes a la BD

Los métodos startup() y shutdown() del módulo manejan el ciclo de vida del pool. El primero carga de un archivo de configuración -que veremos más adelante- los datos para crear el pool y el segundo mata a las conexiones activas.

Mensajería

El servicio de mensajería también es sencillo, pero potente. Poseé un pool de hilos que procesan los mensajes en form asíncrona. La clase Messaging tiene un conjunto de MessageHandlers que son los responsables de procesar los mensajes. Cuando llega un mensaje, este se le pasa a todos los handlers y cada uno es responsable de si lo procesa o no.

Diseño del servicio de mensajería

En el próximo artículo voy presentar la configuración del servidor y también voy a subir el código fuente. Hasta el próximo!

En esta sección se tratará todo lo concerniente a la experimentación con distintos lenguajes de programación.

En el primer artículo (en el cual estoy trabajando) implementaremos RPC en Java. Para que sea “divertido”, este RPC va a ser multi-hilo del lado del servidor (capacidad de atender muchos pedidos a la vez) y también multi-hilo del lado del cliente (capacidad hacer múltiples invocaciones a la vez)

Hasta pronto!

Esperamos en breve estar en contacto.

Gracias