#happypath

[quotesandnotesshewrote]

Theme: #Happy #Poeticnotes 37 Stay on that happy path, keep moving forward, remain in love with your soul and give it all that you've got. 💙 #blueheart #love #happypath #moveforward #loveyoursoul #quotestoliveby #quotesoftheday #clairemariepoeticnotes #writingwithlove #creativespirit (at Marylebone London) https://www.instagram.com/p/Bs8oiVHFMxs/?utm_source=ig_tumblr_share&igshid=h6s0i1wqt9ih

[k-carlyle]

GPS Search for Purpose Take a short stroll with me and share your thoughts.  Glowingly,  The Kelly E. 

[nothappypath]

Not Happy Path

Habrás notado que la mayoría de los errores que se producen en tu código nunca son detectados de manera sencilla ni resultan evidentes. La razón es bastante simple y obvia: los bugs no suelen aparecer en el happy path. No es el lugar habitual donde los desarrolladores ponemos los bugs.  Somos un poco más rebuscados y preferimos introducir los errores en situaciones en las que es necesario realizar muchas acciones previas, invocar alguna deidad y de paso esperar alguna conjunción astral. Si fuera por nosotros no estarían ahí, de verdad, pero el caos a veces sea dueña de nuestros deditos y no podemos parar de cagarla.

La causa de que el grueso de los errores de una aplicación nunca estén en el happy path y que se encuentren tras las pruebas de validaciones manuales es que no somos muy buenos probando nuestro código, especialmente mediante unit testing. La mayoría de las veces nos conformamos con crear los test que cumplen los casos básicos, lo que el usuario va a realizar la mayoría de las veces. A veces somos  un poco más cuidadosos y revisamos el código de manera superflua para comprobar que hemos cubierto todos los casos más evidentes que un usuario normal realizara. Esto es una muy mala práctica que nos va a acarrear a la larga importantes quebraderos de cabeza.

Mientras exista un solo caso que no probado no podemos afirmar que nuestro código cumple los requerimientos, ni mucho menos asegurar la calidad del código que entregamos. Basta con que un usuario realice una acción que provoca un error para que las consecuencias puedan ser no solo fatales para la aplicación sino para los datos del usuario.

Es importante asegurar la calidad pero más importante aún es asegurarnos de que el código que escribimos hace únicamente lo que esperamos que haga. Para ello es imprescindible realizar tantos test como sean necesarios hasta tener la certeza de que entregamos lo que pretendemos. La consecuencia directa de este testing exhaustivo es que ante cualquier modificación del código tendremos una base de test sobre la que apoyarnos para saber si las cosas están bien o debemos tomar acciones correctivas.

En el día a día de un desarrollador lo normal es encontrarse continuamente con un not happy path, no es un caso que provoca un error o que no se pueda realizar una acción. Es el caso al que nadie le presta atención hasta que es demasiado tarde, la excepción que va a provocar que todo tu diseño no valga nada puesto que no están contemplando el caso particular y remoto. Y de esto va este blog: de las cosas que al final del día te pueden facilitar evitar y resolver estos not happy paths que acechan donde menos te lo esperas.  

Pista: Los IDE actuales tienen herramientas de cobertura de código para los test que nos pueden dar buenas pistas de que partes del código estamos probando, pero en ningún caso esta es una métrica que nos asegure la calidad por si sola.