Mostrando entradas con la etiqueta Java. Mostrar todas las entradas
Mostrando entradas con la etiqueta Java. Mostrar todas las entradas

enero 26, 2011

Testeo defensivo, o que disparen a ese API

A raíz de una entrada de @sergioazo y su correspondiente conversación, he recordado una técnica que leí en algún sitio para minimizar los problemas en el trabajo con librerías externas de terceros en tu proyecto.
Se puede usar para varias cuestiones:
  • Comprender el funcionamiento real de una librería (no el esperado)
  • Defenderte frente a cambios en el comportamiento futuro de la librería
  • Documentar el uso de una librería, su API.
Se puede decir que vamos a generar test unitarios, en los que no podemos escribir el nombre del método de test hasta el final. Si hacemos TDD, el nombre del test deberá indicar que comportamiento queremos asegurar, y después programamos ese test. En este caso, podremos poner un nombre al método realmente coherente al test, cuando ya tenemos los assert ejecutando y comprobados en verde. Quizás coincida con lo esperado, o quizás no. Sugiero que se guarden los dos nombres, para comprender las diferencias encontradas, que probablemente también desconcierten al próximo programador que coja tu código que usa esa librería.

Si tenemos tests de los usos que hace nuestra aplicación de una librería, el cambio de versiones de la misma, puede ser testeado. Basta con ejecutar nuestra suite de integración, para que nos corrobore si la librería sigue funcionando tal y como esperamos.

Veamos un ejemplo. Imaginemos que tenemos un API tal que así:

public String guardaDocumento(String docType, byte[] data);
public byte[] obtenerDocumento(String docCode);

Y no tenemos más información, parece bastante obvio lo que hace, pero queremos asegurarnos, y sobre todo tener cuidados con los cambios con esa librería que se está desarrollando. Podemos hacer un test de la siguiente manera:

public void deberiaDevolverElMismoDocumentoPorCodigo(){
Repositorio repositorio = new Repositorio();
String docCode = repositorio.guardaDocumento("tipo1", "Hola Mundo".getBytes());
assertArrayEquals("Hola Mundo".getBytes(),
repositorio.obtenerDocumento(docCode));

}
Pero, este test, tan simple como almacenar un documento y obtenerlo de nuevo, se queda en rojo. ¿por qué? Por que resulta que el código necesita después, no es el mismo código que devuelve
Por lo que finalmente tras unas pruebas (o un telefonazo a alguien harto de tus preguntas) llegamos a la conclusión, que el código que necesita el "obtenerDocumento" es la concatenación del tipo de documento y el código devuelto al guardarlo.
Por tanto, modificamos el test, y después modificamos el nombre del test.

/**
* was:deberiaDevolverElMismoDocumentoPorCodigo
*/
@Test
public void deberiaDevolverElMismoDocumentoPorTipoDocumentalYCodigo(){
Repositorio repositorio = new Repositorio();
String docCode = repositorio.guardaDocumento("tipo1", "Hola Mundo".getBytes());
assertArrayEquals("Hola Mundo".getBytes(),
repositorio.obtenerDocumento("tipo1" + docCode));
}
¿conseguimos con esto los objetivos inicialmente planteados?

(nota:basado en hechos reales)

septiembre 10, 2009

Buscamos desarrolladores JAVA para Biko

En Biko estamos ampliando el equipo JAVA en San Sebastian (Guipuzcoa). Si quieres trabajar con nosotro, escríbemos a unete[at]biko2.com, referencia "desarrollo JAVA".

¿Qué hacemos? Desarrollamos productos con metodologías ágiles, intentamos mejorar tras cada retrospectiva, estamos en implantación de TDD, utilizamos integración continua,... nuestro ecosistema software es: Maven2 + SVN + Hudson + JIRA (GreenHopper). Y las herramientas de desarrollos, las más típicas, Spring e Hibernate, y el viejo Struts que pronto debemos migrar. (¿te atreves a venir a decirnos a cual y enseñarnos?)
Bueno, meto esta cuña publicitaria para encontrar (Septiembre 2009) gente que se venga a trabajar con nosotros. Nunca había comentado cosas en el blog de la empresa, pero quizás os interese este tema.

abril 30, 2008

Escenarios ante "SpringSource Application Platform"

Tenemos una nueva plataforma de aplicaciones JAVA: SpringSource Application Platform. Es una plataforma que no cumple JEE completamente, y de hecho no parece que lo vayan a hacer. Soportan los módulos web como WAR, pero no se asoman los EJBs.
¿Necesitamos otra plataforma de aplicaciones en el mundo JAVA? Creo que no. El punto fuerte de esta nueva plataforma parece que va a ser la utilización de una plataforma OSGI. Esto puede ser un respaldo muy fuerte para esa arquitetura que no acaba de despegar en las aplicaciones reales. Pero tampoco es tan necesario, ni las ventajas que aporta son tan decisivas, nada que no se pueda hacer en el estandar JEE.
Como comenta Martín, esto podría ser un punto de inflexión en el mndo JAVA empresarial. Si se rompe la unidad sobre la plataforma JEE, podemos acabar con una de las ventajas más importantes: la interoperabilidad. Es cierto que ya hay muchas lineas de arquitecturas diferentes en JEE, pero la fuerza de Spring actualmente en muchos desarrollos pueden dar una fuerza muy importante a esta nueva plataforma.
De todas maneras, siempre es genial ver cómo hay gente que no se cansa nunca y tiene ideas novedosas y mejoras en un mundo en el que para algunos las cosas se han anquilosado demasiado. Y además, ahora ya tenemos un juguete nuevo para cacharrear :).

mayo 28, 2007

Infraestructura web JAVA

¿Qué harías si sabes que cualquier cosa (herramienta, framework,...) que elijas sabes que la vas a tener que cambiar en unos años? Pues prepararte para el cambio: buscándolo.
El montaje que hemos realizado para los desarrollos JAVA sigue la clásica configuración de tres capas: presentación, servicios y persistencia, intentando no atarnos a ninguna tecnología demasiado de la que nos sea imposible prencindir en un momento dado.
La elección de las tecnologías depende de muchos factores que no son solo tecnológicos, como el conocimiento con el que puedes contar en la organización para empezar a trabajar, o la disponibilidad de personas formadas para una posible contratación. Después ver que eficacia y eficiencia puedes esperar de ellas.
  • Presentación: Necesitas un framework ágil, en el que se pueda ser eficiente y rápido desarrollando la interfaz. Ese framework no es Struts 1.X., ¿podrá ser Struts 2, o Wicket? Hay muchas opciones en esta capa. Ahora hemos elegido Struts 1.x... jeje, sí, ese que no es ágil y es pesado de desarrollar (muchos xml, clases), por que era donde teníamos mayor conocimiento y experiencia.
  • Servicios: Al decidir seguir una arquitectura basada en servicios, debes decidir también como va a ser el acceso a los mismos: EJBs, clases locales, servicios web... La opción que parece que ofrece más flexibilidad es Spring. Permite la utilización de IoC de manera que nos facilita el acceso a los servicios inyectándolos en la capa de presentación, y además tiene utilidades para hacer transparente el cambio de EJBs a clases o viceversa.
  • Persistencia: Para proyectos que no requieren de excesivo énfasis en el rendimiento, un framework de persistencia objeto-relacional parece hoy en día la opción más interesante. Aquí vamos con Hibernate.
Spring es una pieza muy importante en esta arquitectura que estamos implementado. Es un poco el pegamento entre las capas, y además ofrece muchas prestaciones interesantes: gestión de transacciones, aspectos, soporte de pruebas unitarias,...
La evolución de esta arquitectura está clara:
  • Migración de Struts 1.x a otro framework, que sea más ágil, ofrezca una velocidad de desarrollo mayor y basado en plantillas que la gente de diseño pueda tocar más fácilmente. Wicket parece una gran opción.
  • Eliminación del trabajo manual de modelado de la persistencia. Hibernate Annotations simplifica el trabajo de mantenimiento de la persistencia, pero la automatización del proceso es un objetivo más ambicioso. Estuve probando androMDA, pero la verdad que no lo hice funcionar satisfactoriamente.
  • Despliegue automático de las aplicaciones en versiones EJBs o clases locales o servicios web. Una vez que se tiene las clases de implementación de los servicios, un objetivo sería poder desplegar los mismos de manera automática en cualquier plataforma.
¿Qué más ideas se os ocurren? Obviamente hay mucho más que hablar sobre arquitectura, estais invitados. :)