De TDD y otras hierbas
24 08 2008
He andado un poco ausente debido a un viaje y diversos proyectos, pero estamos de regreso para seguir con el blog.
Uno de los perfiles que mas he notado en los C.V. que nos llegan a la empresa es de un programador parecido a este:
- Uso de Java 1.4 y un poco de J2EE
- Servidor de aplicaciones utilizado Tomcat, Websphere Application Server o JBoss
- Manejo de algún framework como Spring o Struts.
- Manejo de algo de JavaScript pero sin llegar a usar una libreria de AJAX.
Normalmente los programadores con esas características son buenos usando ese set de tecnologías y todo va bien en las entrevistas hasta que preguntamos, ¿Cómo realizas tus pruebas unitarias? ¿Usas algo de TDD?
Si eres un programador que no sabe a que me refiero con las 2 preguntas anteriores o eres como algunoes que he escuchado que tienen diversas excusas para no probar su código, excusas como las siguientes: “¡No tenemos tiempo para pruebas!” ó “Las pruebas unitarias no nos van asegurar el éxito” , no te sorprendas ni aflijas, eres de la mayoria de los programadores que no prueban su código, la buena noticia es que no es muy díficil comenzar y que te va a dar muchas ganancias. El gran valor de las pruebas unitarias es que te forza a pensar y resolver con anticipación estas preguntas sobre tu código:
- ¿Cómo *fregados* pruebo esto?
- ¿Cuáles tests debería crear?
- ¿Cuál es el camino feliz?
- ¿Cuáles son los casos poco comunes?
- ¿Cuántas dependencias tenemos?
- ¿Cuáles son las fallas que debería encontrar aquí?
Pero esto es sólo el comienzo en caso de que tu código este hecho, piensa por un momento que pasaría si sigues los siguientes pasos:
- Usando la librería de tu preferencia, escribe una prueba que llame a tu cógido pidiendole el resultado esperado y que como el código no existe todavía esta prueba fallará, esta prueba al fallar probocara una barra roja en la mayoría de los IDE’s.
- Crea tu código de manera que pase la prueba pero nada más, esto te dara un barra verde, pero si necesitas revisar alguna excepción por ejemplo, primero modifica el test para que falle.
- Limpia el código para eliminar redundancia y que sea legible.
- Conforme crezca tu paquete de pruebas puedes usar ant, rake o algúna tecnología que te permita correr tus pruebas con un simple comando. Ejemplo “ant tests.run”
Esto es conocido como Test Driven Development y te brindara muchas ganancias. Sobre todo que podras estar seguro de que remperas menos el build y no te enviaran fotos como esta cada vez que lo hagas.
Categories : Uncategorized














