Spoiler Alert ⚠️, cuando hablo de pruebas automatizadas no me refiero solo a Test Driven Development (TDD).
La construcción de productos de software es una constante, realmente nunca terminas, esto es algo comúnmente aceptado en la industria.
Una de las partes más satisfactorias es ese proceso de crear algo desde cero, o de poder resolver un problema con código.
Cuando desarrollas software para ti, lo más importante es disfrutar el proceso y en ese camino es posible que no quieras o debas crear pruebas automatizadas, no hay ningún problema con ello. Pero cuando estás buscando crear software que será utilizado por muchos usuarios, que deseas que escale, que quieres mantener a largo plazo, definitivamente debes de tener pruebas automatizadas.
Normalmente las empresas en donde el software no es su producto principal tienen miedo de invertir en pruebas automatizadas creen que no les dará retorno de inversión, porque será más lento el desarrollo, incluso piensan que el software sufrirá cambios mínimos, por eso no será necesario.
No quieres revisar toda la aplicación cada vez que haces un cambio
Imagina que estás trabajando en un bug fix y para comprobar que lo resolviste de forma correcta debes de probar, además de lo que modificaste, toda la aplicación. Esto es algo que no quieres hacer, prefieres dárselo a alguien del equipo de QA.
Probar manualmente normalmente incluye ejecutar una serie de pasos por ejemplo, hacer login, ingresar al módulo que necesitas, llenar formularios, click en guardar, validar en base de datos, uff… y eso múltiples veces para comprobar que tus cambios están funcionando correctamente, cuando esto lo tienes que hacer muchas veces, terminas hacerlo con menos atención e incluso evitando pasos, ahora lo más importante es cerrar esta tarea y pasar a la siguiente. No hay valor, hay esfuerzo.
Automatizar tus pruebas te permitirá que esos escenarios se prueben por si solos sin que tú te preocupes, en ese inter puedes abrir Twitter o TikTok y tomar un descanso, deja a los procesos automáticos trabajar por ti.
Ahorrar Tiempo
Este argumento es difícil de defender, porque desarrollar pruebas automatizadas bien hechas toma tiempo, pero intentaré explicar por qué terminas ahorrando tiempo, yo tampoco lo creía.
El setup inicial de las pruebas automatizadas toma tiempo y esfuerzo, eso sin duda alguna, el tiempo de ejecución de las pruebas automatizadas es mucho más rápido que el de las pruebas manuales.
El tiempo que inviertes en un release en probar todo el sistema es significativamente menor cuando tienes pruebas automatizadas. Todo ocurre de forma automáticamente.
Necesario para Integración Continua (CI) y/o DevOps
Las empresas buscan crear procesos automatizados que den libertad a los equipos de desarrollo de software que les permita agilizar el proceso entre que un feature o bug son definidos hasta que llegan a producción a los usuarios finales.
Los tests automatizados son importantes cuando hay un setup de Integración Continua y/o DevOps, debido a que ambos dependen de la filosofía “Falla rápido, falla pronto” (Fail fast, Fail early). Cada commit de código deberá ser probado y los resultados reportados a quien escribió el código, además deberán de arreglar pruebas que pudieron haberse “roto” con el nuevo código que escribieron. El build del producto siempre debe ser estable.
Es muy común que los pipelines de Integración Continua ejecuten las pruebas automatizadas e impidan que puedas integrar tu código a otras ramas si las pruebas no funcionan.
Eventualmente te van a salvar, cuando menos te lo imagines
Todos los que escribimos código eventualmente hemos cometido errores, errores que han llegado a los ambientes de producción, descubriste el problema después de que los clientes se enojaron… no son errores de lógica de negocio o derivados de que los requerimientos no eran lo esperado… sino de errores obvios, variables con typos, tags que no cerraste correctamente… un cambio que parecía mínimo y resultó tener más consecuencias que las que anticipaste.
Las pruebas sirven como documentación
A veces llegas a una sección de código, no la entiendes y entonces recuerdas esa frase de “Solo quien escribió esto, sabe cómo funciona”. Pues las pruebas automatizadas te ayudan a que otras personas entiendan como es que funciona la aplicación, entre más información compartas en ellas acerca de los casos normales y los casos raros más personas podrán comprender el porqué algo fue desarrollado de esa forma, dan contexto a tu equipo.
Conclusiones
En estos días no hay excusa para no hacer pruebas automatizadas, todos los lenguajes modernos y frameworks permite que sea bastante sencillo. Aun así hay desarrolladores que no querrán escribir ellos mismos sus pruebas, argumentarán que eso los hace más lentos, que en eso no deben de pensar ellos sino los equipos de pruebas.
En mis tiempos las pruebas automatizadas no eran parte de los procesos de desarrollo de software, eran vistas como un gasto más que como una inversión, no eran algo que nos enseñaran.
Tampoco creo que deba existir un 100% de code coverage, me parece que no es necesario, o no deberías de tener el 100% de code coverage en software, porque el software evoluciona constantemente.
Puedes buscar en Google: Lenguaje + Automated Tests y encontrarás la información que necesitas para iniciarte en este camino, a mí me costó trabajo. Aquí también hay un buen listado el cual puedes consultar: [https://testguild.com/automation-testing-tools/]
Sigo trabajando en mis productos con el fin de ayudar de forma más estructurada a la comunidad de TI, si te interesan pásale a mi perfil de Gumroad
- 📕 Líder Técnico
- 📘 De Junior a Senior
- 🗓 Mentorías
- 📑 Revisión de C.V.
Te invito a que me sigas en Twitter para que te enteres de todo el contenido que hago normalmente 🙃.
También soy creador del podcast Chile, Mole & Tech(https://dev.to/chilemoleytech), el cual esta en todas las plataformas(https://linktr.ee/chilemoleytech).
** Si te gusto este post, no dudes en compartirlo, me ayuda mucho. **
Top comments (0)