TuLista 2.15

¡Versión 2.15 ya disponible en Google Play!

Además de lo que se mejoró en la versión 2.14

Para facilitarte la confección de la lista, se muestra en el historico los productos que has seleccionado actualmente con letra cursiva (o italica lis lo prefieres) junto con la cantidad, si has seleccionado mas de uno. De esta forma no tendrás que estar volviendo a la lista para revisar si habias o no añadido un producto.

Se ha cambiado el color de la entrada para que sea mas fácil de distingir.

Captura2_v22

 

Recuerda que si quiere sugerir algo o simplemente saludar, puedes acceder a la página de facebook
https://www.facebook.com/TuLista

No la tienes aun, ¿a qué esperas a descargartela? ¡Es gratis!


Android app on Google Play

https://play.google.com/store/apps/details?id=es.blackpent.tulista

TuLista 2.14

¡Versión 2.14 ya disponible en Google Play!

Para facilitarte la confección de la lista, se muestra en el historico los productos que has seleccionado actualmente con letra cursiva (o italica lis lo prefieres) junto con la cantidad, si has seleccionado mas de uno. De esta forma no tendrás que estar volviendo a la lista para revisar si habias o no añadido un producto.

Recuerda que si quiere sugerir algo o simplemente saludar, puedes acceder a la página de facebook
https://www.facebook.com/TuLista

No la tienes aun, ¿a qué esperas a descargartela? ¡Es gratis!


Android app on Google Play

https://play.google.com/store/apps/details?id=es.blackpent.tulista

Test de Integración vs Test Unitarios

Introducción

Desde hace cierto tiempo la comunidad de desarrolladores y empresas del sector se están concienciando de la importancia de tener definido e implementado un sistema de pruebas sobre el software desarrollado. Para dar soporte a estas pruebas nacieron una serie de frameworks y herramientas como la familia xUnit y entornos de integración continua como Hudson.
¿Cómo se implementan estas pruebas? Básicamente podemos definir dos tipos, Pruebas de Integración y Pruebas Unitarias, cada una de las cuales tiene sus particularidades, comencemos por su definición.

Definición

Tomando las definiciones recopiladas en el blog de  PSDM Consulting podrían definirse como:

  • Prueba unitaria: prueba un único método de una clase. El alcance es muy reducido y está perfectamente acotado. Cualquier dependencia del módulo bajo prueba debe ser sustituida por un mock, o un stub.
  • Prueba de integración: prueba la interacción entre dos o más elementos, que pueden ser clases, módulos, paquetes, subsistemas, etc… incluso la interacción del sistema con el entorno de producción.

Ventajas y desventajas

Conociendo las ventajas y desventajas quizás podamos tener los datos suficientes para tomar la decisión de cuándo usarlas ya que hay distintas posiciones frente al tipo de test a utilizar.

Velocidad de ejecución

Definiendo velocidad por el tiempo que se tarda en ejecutar una prueba de este tipo, podemos afirmar sin realizar ninguna prueba empírica que lo Test de Integración deben ser más lentos de ejecutar que los Test Unitarios, ya que los Test de Integración ejecutan más líneas de código que un Test Unitario que se dedica solo a un método. ¿Cuál es la diferencia de tiempos? Esto depende tanto del código como del framework utilizado para las pruebas y mocks ya que un framework con objetos mocks muy lentos podrían penalizar los tiempos de ejecución de los Test Unitarios e igualar estos tiempos.

Velocidad de implementación

Los Test Unitarios consisten en las pruebas de métodos específicos y atañe sólo al código encerrado dentro de dicho método. Cada acceso al “exterior” es simulado mediante un mock.
Resumiendo mucho tendríamos que implementar un test por cada conjunto de valores de entrada a probar, así como crear los mocks necesarios para cada test.
En los Test de Integración evitamos, en la mayoría de las ocasiones, tener que crear mocks. La complejidad radica en crear las condiciones iniciales (datos iniciales en la BBDD u otros sistemas)  para ejecutar el test, que como apunta Adam Kolawa son fundamentales para que los Test de Integración sean realmente válidos.
Suponiendo que solo tenemos una interfaz para acceder a la aplicación, se debería implementar un conjunto de Test de Integración (en función de los valores de entrada y condiciones iniciales) por cada método esta interfaz, mientras que para los Test Unitarios, tendríamos que implementar un conjunto de test por cada método de cada clase que compone el software que estamos desarrollando.
Imaginemos que implementamos un solo test por método y que nuestra arquitectura corresponde al siguiente esquema, teniendo cada nivel una sola clase.
Service -> Manager -> Dao

Suponiendo que cada clase tiene 5 métodos necesitaríamos: 5 Test de Integración, frente a 15 Test Unitarios. En un caso real, tendríamos variasias clases por nivel sin contar con las clases de utilidades, esta diferencia se hace notoriamente mayor.

Cobertura de código

Si definimos cobertura como las líneas de código recorridas durante la ejecución de un Test, podemos decir que los Tests de Integración recorren mucho más código que los Unitario ya que pasan por más regiones de código. Sin embargo y dependiendo del diseño del código, habrá regiones de código que requieran de complejas condiciones iniciales para que el código sea alcanzado por un Test de Integración lo cual es un punto “en contra” de los Test de Integración, y lo pongo entre comillas por una razón que veremos más adelante.

Mantenibilidad de los Tests

Este es un punto muy controvertido. Mientras que algunos mantienen que los test unitarios son más fáciles de mantener otros, que los test de integración son más fáciles de mantener pero la verdad que siempre dependerá de los tipos de cambios a los que se vean sometidos el código.
Veamos varios escenarios y cómo afectan a los Tests.
– Cambios en clases intermedias que no afectan a los resultados, por ejemplo una refactorización que no afecta a los interfaces: En este caso los test de integración no tienen por qué verse afectados ya que tratan al código como casi una caja negra, sin embargo todas las clases y métodos modificados requerirán de modificación de test unitarios y mocks usados.
– Cambios en el comportamiento general de la aplicación: En este caso tanto los test de integración que esperaban cierto resultado se verán afectados como  los test unitarios que probaban las clases y métodos modificados.

Utilidad para la Mantenibilidad del código

Durante el desarrollo  del software los Test Unitarios nos dan información de qué método es el que está fallando o no da el resultado esperado por el Test. Esta cualidad es muy ventajosa para el desarrollador ya que el Test lo conduce directamente hacia el método a corregir.
Los Test de Integración dan una visión más global convirtiéndose en una poderosa herramienta para realizar las pruebas de regresión. Son capaces de detectar errores producidos durante el tratamiento de la información que no se producen de forma local a un método. Como desventaja , el Test de Integración no conduce al desarrollador al método que produce el error y requiere de depuración por parte de este, sin embargo detectar el error que un Test Unitario no podría es un a ventaja a tener en cuenta.

Proximidad a las pruebas de aceptación

Una de las ventajas que ofrecen los test de integración que no pueden aportar los test unitarios es la implementación de las pruebas de aceptación sobre el software.

Cobertura falseada por los test unitarios

Como comentaba en el apartado de cobertura, se podrían dar regiones de código que pueden ser difícilmente alcanzable por las pruebas de integración. Si estas regiones estuvieran recorridas mediante pruebas unitarias se estaría ocultando este dato, es decir, no conoceríamos regiones de código que nunca se recorren y que pueden ser reimplementadas para que sea un código realmente útil.

Veracidad de las pruebas

De todos es sabido que imposible implementar, en un tiempo razonable, un conjunto de pruebas que garanticen que un software de cierto tamaño no falle. Y esta imposibilidad aumenta con el tamaño del proyecto. ¿Qué pruebas pueden cubrir más errores? Para tratar de contestar a esta pregunta planteemos la siguiente situación:
Tenemos 5 clases que se llaman en cadena para realizar una operación determinada.
A->B->C->D->E
Si cada clase tiene una probabilidad de realizar su cometido con éxito de un 95%, tenemos que la probabilidad total, al ser llamadas encadenadas, es el producto de sus probabilidades, lo que da un resultado de: 0.95^5 = 0.77. Tenemos un 77% de probabilidad de éxito.
¿Qué significa esto? Podríamos decir, que los test de integración tienen más probabilidades de fallar, y por lo tanto de detectar bugs.
A esto habría que añadir que los test de integración prueban la conexión entre métodos, validando que las clases se invoquen de forma correcta entre ellas.

Conclusiones

Los Test de Integración dan una información global que no puede ser ignorada:
– Pruebas de aceptación.
– Pruebas de regresión.
– Pruebas funcionales.
– Menor número de test para probar la aplicación.
– Mantenibilidad más sencilla.
Los Test Unitarios proporcionan ventajas que tampoco pueden ser ignoradas:
– Es una forma sencilla de probar el código de forma exhaustiva e independiente de otros artefactos.
– Dirigen al desarrollador a la porción de código que falla de forma directa.

En conclusión y en mi opinión los Test de Integración deberían estar siempre en todos los desarrollos mientras que los Test Unitarios deberían ser usados para probar métodos complejos o críticos.

Referencias:

[1]http://psdm.co/2012/01/diferencias-entre-pruebas-unitarias-y-de-integracion/
[2]http://www.codeproject.com/Articles/235724/Integration-vs-unit-tests
[3]http://ix.cs.uoregon.edu/~michal/book/index.html
[4]http://geosoft.no/development/unittesting.html
[5]http://www.parasoft.com/jsp/products/article.jsp;jsessionid=baa4J9YnmGUi0g?articleId=2869&redname=unit-testing-best-practices&referred=unit-testing-best-practices