Imagina que el cliente nos pide que agreguemos una función para saludar a los usuarios. Es muy fácil, pensamos, no hace falta escribir ninguna prueba:
function welcome()
{
return 'Welcome' . auth()->user()->name;
}
En layout.blade.php (suponiendo que estás trabajando con Laravel), llamas a la función de esta forma:
<h1>{{ welcome() }}</h1>
Como es algo tan sencillo y fácil, probablemente tampoco haga falta probar en el navegador, así que subimos el código directamente al repositorio, hacemos deploy y continuamos con la siguiente tarea.
2 minutos después recibimos una llamada del cliente furioso: toda su página está caída.
“Attempting to use the property name on a none object”
Si el usuario no está conectado, auth()->user() va a devolver null, no tomaste la previsión de ese caso. Comienzas a sudar frío y a reparar el error a la carrera, subes una corrección:
function welcome()
{
if (auth()->check()) {
return 'Welcome' . auth()->user()->name;
} else {
return 'Welcome guest!';
}
}
Subes el cambio, haces deploy, abres la página y puedes ver el siguiente mensaje: Welcome guest!
Suspiras. Pero 5 minutos después el cliente vuelve a llamar, te pregunta si probaste el código, le dices que sí, el cliente te pregunta si probaste el código estando como un usuario conectado, sí, por supuesto, mientes, mientras corres a conectarte y ves el siguiente mensaje:
WelcomePedro!
“Me faltó un espacio” le dices al cliente, avergonzado, ya lo corrijo…
¿De verdad era un código muy sencillo que no requería pruebas? ¿Te sientes identificado con esta historia?
Las Pruebas de software buscan detectar errores y posibles deficiencias en los software o el mejoramiento de los mismos.
Una prueba tiene éxito si descubre un error no detectado hasta entonces.
"Las pruebas sólo pueden demostrar la presencia de errores, no su ausencia."
Edsger Dijkstra
Las pruebas de software involucran muchos tipos de pruebas, estas pruebas se pueden clasificar según su tipo, como los son Caja Negra, Caja Blanca y Caja Gris.
También denominadas pruebas de entrada/Salida, son pruebas funcionales dedicadas a “mirar” en el exterior de lo que se prueba.
Se limitan a que el tester pruebe con “datos” de entrada y estudie como salen, sin preocuparse de lo que ocurre en el interior.
.
Ventajas
- Menos conocimiento y habilidades
- Menos tiempo
- Menos herramientas y costos
Desventajas
- Cercanía a la solución de errores.
- Falta de conocimiento de los caminos problemáticos
En ocasiones llamada prueba de caja de cristal, se centran en la estructura de control del programa.