Pruebas unitarias
Probar cdigo nunca tuvo tanta importancia en el ciclo de desarrollo de una aplicacin hasta
hace algunos aos, donde se ha desatado una revolucin en los procesos de desarrollo,
apareciendo nuevas y giles forma de construccin, donde ejecutar pruebas (o al menos pruebas
unitarias) pas de ser un proceso tedioso (como las antiguas que se ejecutaban para cumplir
estndares como el ISO 9001) a ser un forma de trabajo integrada y productiva en los nuevos
procesos de desarrollo.
A pesar de existir diferentes tipos y tcnicas de pruebas (unitarias, de integracin, aceptacin,
carga y estrs), en este artculo hablaremos del uso de Pruebas Unitarias (Unit Test), pues de
todo el conjunto de pruebas, es considerada la ms importante para garantizar un proyecto
exitoso, por tanto debe ser introducida como una actividad ms en el desarrollo.
Que son las pruebas unitarias Son pruebas dirigidas a probar clases java aisladamente y estn
relacionadas con el cdigo y la responsabilidad de cada clase y sus fragmentos de cdigo ms
crticos.
Por ejemplo una clase que envi e-mails, debe ser capaz de probarse aislada chequeando que sea
capaz de enviar e-mails, y asegurndonos de probar todas las posibilidades de fallo y xito. En
un modelo basado en pruebas, se deben definir casos de prueba para cada clase de forma
aislada, una prueba no debe depender de otras clases.
Porque realizar pruebas unitarias
Asegura calidad del cdigo entregado. Es la mejor forma de detectar errores tempranamente en
el desarrollo. No obstante, esto no asegura detectar todos los errores, por tanto prueba de
integracin y aceptacin siguen siendo necesarias.
Ayuda a definir los requerimientos y responsabilidades de cada mtodo en cada clase probada.
Constituye una buena forma de ejecutar pruebas de concepto. Cuando es necesario hacer
pruebas de conceptos sin integrar usar pruebas unitarias se convierte en un mtodo efectivo.
Permite hacer refactoring tempranamente en el cdigo. No es necesario todo un ciclo de
integracin para hacer refactoring en la aplicacin, basta con ver cmo se comporta un caso de
prueba para hacer refactoring unitario sobre la clase que estamos probando en cuestin.
Permite incluso hacer pruebas de estrs tempranamente en el cdigo. Por ejemplo un mtodo
que realice una consulta SQL que exceda los tiempos de aceptacin es posible optimizarla antes
de integrar con la aplicacin.
Permite encontrar errores o bugs tempranamente en el desarrollo. Y est demostrado que
mientras ms temprano se corrijan los errores, menos costar corregirlos.
Tcnicas para hacer nuestro cdigo testearle.
Codificar sobre interfaces ms que sobre clases. Mientras ms usemos interfaces ms
plugabilidad de soluciones tendremos en runtime o testtime. De esta forma estamos probando
el que y no el como y esto es precisamente en lo que debe enfocarse una prueba unitaria
Usar la Ley de Demeter1. Esta ley dice que un objeto solo debe depender de objetos que
estn muy cercanos a l, o sea no debera usar objetos globales.
public class ClaseAProbar implements ServicioAProbar {
....
protected Helper helper;
...
public void metodoAProbar() {
...
[Link](); // BIEN seg n ley de demeter. La clase solo depende de Helper
[Link]().metodo(); // MAL segn ley de demeter pues aqui nuestro
// objeto depende tanto de helper como de SegundoHelper.
}
...
}
Minimizar dependencia sobre APIs especficas de ambientes. Imaginen que seamos capaces
de probar un EJB, sin tener que deplorarlo sobre un EJB Container. Esto ms que una tcnica es
una buena prctica que hemos reiterado a lo largo del documento.
Asegurarnos que cada objeto tiene un conjunto definido de responsabilidades. Objetos con
mucha responsabilidad y dependencias son difciles de probar.
Ocultar detalles de implementacin. Un caso de prueba no debe tener conocimiento de
cmo fue implementado el mtodo que se est probando, de esta forma no tendra influencia
en ello.