Contenido del curso
Para entender la importancia de agregar pruebas a un proyecto, debemos remontarnos tiempo atrás, cuando la industria del software apenas estaba iniciando.
Era el año 1949 y una ilustre persona llamada Alan Turing, estaba discutiendo el cómo poder probar las falencias en una rutina. En ese entonces una rutina se veía algo como esto:
Y existía la práctica de debugging solamente para encontrar esas falencias. Se imaginan que tan difícil debió haber sido el encontrar donde está el error en este tipo de programas.
Por lo cual, fue lógico que empezaran a buscar maneras de automatizar esas pruebas.
De los primeros indicios de unit testing fue el paper Checking a Large Routine por Alan Turing, si tienen el tiempo para buscarlo y leerlo háganlo, es muy bueno.
Historia de automatización del software
Básicamente, la intención, en esos tiempos, era "buscar que el código funcione sin fallos, pero esto solamente nos aseguraba que corría el código y ya."
“Las pruebas de software son el proceso de ejecutar un programa con la intención de encontrar errores” G.J. Myers.
Entre 1957 y 1978, se añadió un nuevo concepto a las pruebas, que no era el debugging, sino el testing.
Este nuevo concepto hace alusión a que el programa no solamente debe de funcionar, sino que debe de resolver la problemática planteada, eso quiere decir, que se tenía una lista de requerimientos que se debían de cumplir y se utilizaban las pruebas para esto.
Estas pruebas se realizaban al final de los programas, después de haber terminado de hacerlo.
Se imaginan revisar ese código después de terminarlo, ¡Sería horrible!
Afortunadamente a principios de 1980 se empezaron a crear programas para que hicieran esta parte. Debido a esto, cambió el panorama de las pruebas. Pasamos de buscar fallas en el código a revisar la calidad del código y de las diferentes implementaciones.
“El objetivo general de las pruebas de software es confirmar la calidad de los sistemas software ejercitando sistemáticamente el software en unas circunstancias cuidadosamente controladas” E.F. Miller.
Del año 1985 a la actualidad se entró en la etapa de prevención. La IEEE empezó a crear estándares para tener pruebas en diferentes partes del proceso de desarrollo de software.
Esto hizo que se viera a las pruebas como una característica de la calidad de todo el proceso que involucra el desarrollo de proyecto de software.
“Hacer pruebas significa comparar los resultados actuales con un estándar” Hutcheson, M.L.
De todo lo anterior podemos concluir que realmente las pruebas son un proceso superimportante en la calidad de nuestro trabajo.
El no tener pruebas en tu proyecto significa, no tener la calidad requerida para que sea considerado dentro del estándar de un buen proyecto de software.
Así que la más grande diferencia entre no tener pruebas o si en tu código, es el no tener código de calidad o sí tenerlo.
Siendo sinceros, no sabía que Alan Turing también había comenzado con esto, escribe en los comentarios si tú ya conocías esto, y si no, ¿qué te pareció?.
