En el mundo de las pruebas de calidad existen un sin fin de escenarios a tomar en cuenta, tanto positivos como negativos. Tal es el caso de valores aceptados, valores no aceptados, pruebas de límites, etc. Lo anteriores casos entran en el tema principal de este blog, el software (aunque no se limitan únicamente al desarrollo de software.)  Todas las anteriores pueden entrar en el espectro de los «happy paths» o las pruebas felices.

Pero ¿a qué se refiere tu lider de pruebas al pedir que realicen algunos happy paths? Bueno, cuando escribimos una nueva clase o añadimos una nueva funcionalidad al código ya existente, tendemos a escribir o realizar pruebas que, de manera consciente o inconsciente, serán exitosas, o bien, nos causarán pocos dolores de cabeza al ser ejecutadas. Probamos entonces el mejor de los casos y cuyo resultado resolverá bien con el código desarrollado, ya sea nuestro (si nos encontramos dentro del equipo de desarrollo) o provisto por el equipo de desarrollo (si nos encontramos dentro del área de QA).

Por ejemplo, el chappy path para una función que valida los números de tarjetas de crédito sería donde ninguna de las reglas de validación genere un error, permitiendo así que la ejecución continúe exitosamente hasta el final, generando una respuesta positiva.

El happy path es un caso de prueba bien definido que utiliza una solicitud o entrada conocida, que se ejecuta sin excepción y produce una salida o respuesta esperada.

Los happy paths nos ayudan al decirnos «tu código funciona bien para lo que lo has desarrollado» sin embargo si nos cierramos a realizar solamente happy paths nos estamos privando a nosotros mismos de tener soluciones sostenidas por pruebas y escenarios sólidos que demuestren que nuestros cambios o funcionalidades nuevas funcionan de manera exitosa.