Los principales cambios son:

• Nueva pestaña en la pantalla principal que permite localizar las paradas cercanas, utilizando el dispositivo GPS del teléfono. Esta pestaña se puede deshabilitar en las preferencias de la aplicación. También se puede configurar la distancia máxima a la que buscar paradas (el rango puede variar de 100 a 600 metros).
• Ahora se puede modificar el nombre de una parada favorita, en el momento de crearla.
• Incluye tres temas, que aplican en conjunto a la app y a los widgets.

Esta versión incluye algunos cambios visuales que simplifican el uso de la app, pero los mayores esfuerzos han estado enfocados a la corrección de problemas relacionados con los widgets y las notificaciones recibidas desde el launcher de aplicaciones.

Esta versión es considerablemente más estable, y supone un buen punto de partida para que las versiones futuras incluyan más funcionalidad:

• localización de paradas cercanas por GPS,
• cáclulo de rutas en bus,
• etc.

Al final, como dice Steve Smith en el artículo de la vía, los desarrolladores acabamos llamando “prueba unitaria” a una entidad de mayor envergadura.

Entonces, ¿cómo se defien una prueba unitaria?

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.

En Stackoverflow hay un thread en el que aparecen esta y otras definiciones, como la de prueba de integración:

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.

Para Steve Smith, un test unitario es aquél que prueba un “único camino dentro de un método concreto”. Y esto es muy importante: es un test que NO tiene absolutamente ninguna dependencia externa. Cualquier dependencia debe ser sustituida por un mock, stub, driver… lo que sea necesario.

Cualquier dependencia (con otras partes de código, con el entorno, etc.) convierte tu test en una prueba de integración.

Necesidad de las pruebas unitarias. Construcción de los mocks

La definición es muy clara, pero ¿en qué casos es necesario ejecutar pruebas estrictamente unitarias?

Mi opinión es que sólo deberían hacerse para métodos críticos desde el punto de vista de la funcionalidad del sistema.

La razón es el coste. Supongamos que vamos a probar un método con dos parámetros enteros, con valores válidos en un rango determinado, complejidad ciclomática 2 y dependencia con otro módulo que devuelve un valor entero (con rango válido) y puede lanzar una excepción. A priori, cabe pensar que para alcanzar un 100% de cobertura de decisión,  y probar valores válidos, inválidos y límites, se necesitan del orden de 10-20 pruebas, además de la implementación de 3-4 mocks.

Ya sé que la aproximación es muy rudimentaria (por no decir chapucera), pero es evidente que el número de pruebas unitarias para alcanzar una cobertura aceptable de TODO el código sería un orden de magnitud superior al número de métodos implementados, y a esto hay que añadir la implementación de stubs y drivers. Es fundamental, pues, identificar los métodos/clases/subsistemas que requieren este tipo de pruebas.

Aproximación

Como sugería en otra entrada, algunas de estar pruebas unitarias pueden ser sustituidas por pruebas de integración si consideramos que el método del que depende nuestro método bajo prueba no es más que “mock muy elaborado”. La condición previa es que este “mock” haya sido probado previamente. En otro caso, no podemos asegurar que el resultado de la prueba sea correcto.

Cierto que las pruebas de integración son más lentas que las unitarias en ejecución, pero son igualmente automatizables (en raras ocasiones el desarrollo de un módulo va por delante del desarrollo de sus dependencias), y, puesto que los diseños detallados (al menos en nuestro país) brillan por su ausencia, dan una mejor idea del estado global de completitud del proyecto, pues aportan imformación, aunque se parcial, de la funcionalidad desarrollado hasta el momento.

Además, las pruebas de integración presentan una ventaja: las entradas y resultados obtenidos debe tener, al menos, consistencia lógica desde el punto de vista funcional, mientras que las unitarias suelen ser mucho más abstractas.

Conclusión

Ejecutar las pruebas unitarias mínimas necesarias para asegurar una robustez acorde a la criticidad de las aplicaciones desarrolladas. Para todo lo demás, de integración y funcionales.

Vía | Unit Test or Integration Test and Why You Should Care

Pruebas Unitarias

Raras veces se escriben pruebas unitarias, por el coste de desarrollo y mantenimiento, y, cuando se hace, el enfoque suele ser incorrecto. Habitualmente se escribe pruebas en que se pasan unos argumentos y se comprueba si el resultado es correcto.

Este tipo de pruebas normalmente cubre los casos positivos, quizás también algunos de los negativos, desde un punto de vista lógico. Pero, ¿qué ocurre con las “excepciones”?

Es importante tratar los valores límite. Si los argumentos son objetos, probar, por ejemplo, que el comportamiento es correcto cuando pasamos un puntero nulo.

Una buena idea sería pedir a un desarrollador que haga las pruebas unitarias de un módulo desarrollado por otro, dándole a conocer sólo los interfaces. Con esto:

• las pruebas no están sesgadas por conocimientos de “caja blanca”;
• detectamos si la especificación de un interfaz no es auto-explicativa (lo cual crearía problemas de mantenimiento).

Mocks: stubs, drivers, simuladores…

Problema: testing de módulos de “alto nivel”, cuando los de bajo nivel no han sido probados.

Desarrollar simuladores “ad hoc” no suele ser buena idea, porque están fuertemente acoplados, son poco mantenibles. Existen frameworks que ayudan a independizar los stubs utilizados del código.

En mi experiencia profesional, la mejor solución es utilizar los módulos originales, siempre que éstos estén implementados. Por supuesto, se tienen que haber probado siguiendo la jerarquía de dependencias. En otro caso, no se puede asegurar que los errores se deban a los módulos bajo prueba.

Tests de Integración

Si se sigue mi consejo del párrafo anterior, los tests de integración estarán prácticamente cubiertos, siempre que el enfoque se haya hecho a la funcionalidad por módulos, y no por unidad de compilación.

Estos tests son muy importantes porque deben asegurar que cada paquete, como caja cerrada, funciona correctamente. Como ejemplo podemos tomar una aplicación que accede a DB mediante Hibernate. Las pruebas de integración asegurarían que el paquete correspondiente ejecutan las operaciones CRUD correctamente, from end to end. Pero nada más.

Para este tipo de pruebas sería conveniente una especificación en formato “tablas de datos de entrada”, que permita una ejecución independiente de la implementación, o al menos permita una adaptación rápida, a través de, por ejemplo, una herramienta que actúe como puente. [El autor del artículo original cita la lectura de una hoja Excel, utilizando la clase XlsDataSet de DbUnit. Esto es sólo un ejemplo.]

Tests Funcionales

Evidentemente, la automatización de los tests funcionales es costosa. Pero el coste de mantenimiento y ejecución, si no se automatizan, es mucho mayor.

Existen montones de frameworks que pueden ayudarnos a automatizar las pruebas, herramientas que permiten incluso grabar una secuencia de eventos de usuario para repetirlos posteriormente.

En este punto, es importante estructurar y ordenar bien la ejecución, crear, no solo tests, sino test suites, favoreciendo la reutilización. Como ejemplo, el test “apertura de sesión” puede ser reutilizado en todas las operaciones (modificación de datos personales, compra de algún artículo, etc.) que tenga como requisito previo que el usuario esté logado.

Además, deben probarse los flujos lógicos de ejecución, no solo las operaciones individuales que pueden efectuarse. Los interesados tienen mucho que decir en este punto. Es un error muy común que el desarrollador siga unos pasos de ejecución diferentes a los que un usuario considera lógicos.

Diseño orientado al comportamiento BDD

A menudo los tests tienen una orientación excesivamente técnica. Si se han identificado correctamente los interesados y la especificación funcional es bastante completa, puede hacerse una buena aproximación al diseño final a través de la descripción del comportamiento que debe tener el sistema frente a las acciones del usuario. De aquí resulta sencillo inferir las pruebas, y, a partir de estas, pasar a un diseño técnico y una implementación dirigida por los tests: TDD.

Vía | about:software development