Testing

Lee algo acerca de TDD (Test-Driven Development) para que entiendas las razones filosóficas detrás de las pruebas unitarias. Hudson es para integración contínua, va un poco de la mano con TDD pero por sí mismo el concepto de pruebas de integración no requiere que uses Hudson ni ninguna herramienta en particular (tampoco pruebas unitarias, pero pues si ya existe jUnit o TestNG no hay necesidad de complicarse la vida haciendo todo desde cero).

Espero esto te sirva un poco: La idea de las pruebas unitarias es que desde el principio te quede muy claro lo que debe hacer tu software, a muy bajo nivel. Digamos que tienes que hacer un componente que valida una factura y le pone el 16% de IVA al subtotal, o el 11% de IVA si la factura fue hecha en un estado fronterizo. Puedes definir las puras interfaces que necesitas o los puros esqueltos de tus objetos, y una vez que tienes eso, puedes crear las pruebas unitarias. Una prueba por ejemplo es que hagas una factura de 5 estados no fronterizos (DF, Querétaro, Puebla, Veracruz, Guerrero) y verifiques que el IVA que se le aplica es 16%. Otra prueba es que hagas una factura de los estados fronterizos (o ciudades, no recuerdo si aplica a todo el estado, en fin) y verifiques que el IVA aplicado sea 11%. No tienes que tener todo ya funcionando para poder escribir el código de las pruebas unitarias. Se llaman unitarias porque prueban partes muy específicas de tu código; en OOP idealmente debes estar probando un solo método, que se puede ver como una unidad funcional de un objeto, de ahí el nombre.

Cuando ya terminas de codificar lo de las facturas (o al menos cuando terminas de codificar las partes que necesitas y que ya quieres probar), corres las pruebas unitarias correspondientes y de inmediato sabrás si tu código está bien o no. El chiste es saber definir las pruebas unitarias y diseñarlas bien. Por ejemplo puedes hacer que todos los programadores le sepan bien a lo de las pruebas unitarias y entonces el programador A crea las pruebas unitarias de lo que va a hacer el programador B, mientras que B hace las pruebas para lo que va a programar C, que hace las pruebas de lo que va a programar A... todo se hace de acuerdo a la especificación de lo que tienen que hacer sus componentes.

Muchas gracias por la explicación, me aclara mucho

Una duda muy especifica que tengo es la siguiente:

Tengo un servicio (A) que se conecta a otro servicio remoto (B) y quiero hacer una prueba unitaria, pero obviamente para poder hacer la prueba unitarias de (A) necesito que (B) esté disponible o arriba. Entonces cada que hago mi prueba unitaria de A pues tengo que levantar a mano (B) para poderla correr.

Mi duda es: ¿Es correcto mi esquema? Siento que no debería depender A de B para pruebas unitarias pero no estoy seguro de ello...

Gracias nuevamente

Esa es la bronca principal de las pruebas unitarias, ese tipo de dependencias. La solución es tener un componente B que sea un mockup, es decir no el verdadero componente B sino una versión muy simplificada del mismo, para que A pueda tener la referencia a B y puedas hacer tus pruebas.

Si usas Spring, puedes tener un application context distinto para tus pruebas unitarias, donde ya tienes ese mockup (o incluso el componente B real pero conectado a su vez a otros mockups para que no necesites toda la maraña de objetos interconectados solamente para una prueba). De hecho Spring tiene unas anotaciones bastante útiles para complementar jUnit con esto de los contextos y puedes ponerle también autowired y cosas así a tu objeto de pruebas.

Es inevitable eso de las dependencias, y pues no hay una solución que aplique para todos los casos.

Ok, gracias nuevamente por la explicación. Después de leerte estoy más claro sobre para qué sirven los Frameworks de Mock:simulan ambientes para no tener que estarlos levantando para hacer las pruebas.....
Supongo que las pruebas de integración es probar todo pero ya sin mocks ....

Bien, muchas gracias

He visto que tambien esta en el proyecto javamexico 2.0 esa carpeta, pero como se puede integrar? en cualquier IDE?

Los proyectos de Maven traen una estructura que por ejemplo para Java te dan src/main/java y src/test/java, sabiendo que en src/main/java va el código de tu aplicación (o librería o lo que sea) y en src/test/java van las pruebas unitarias, incluso para src/test/java incluye TestNG o jUnit en el classpath. En javaMexico 2.0 tenemos pruebas unitarias configuradas para los DAOs, con eso se pueden dar una idea de cómo montar pruebas unitarias con jUnit y Spring.