Planificación de pruebas

Al empezar un proyecto de pruebas automatizadas (o al evolucionar un proyecto existente), me gusta comenzar haciéndome las siguientes preguntas:

1. "¿Cuál es la funcionalidad principal de la aplicación, la que, si no funciona, no satisface las necesidades de los usuarios?"
2. "¿Qué casos de prueba se van a implementar?"
3. "¿Qué pruebas son las más importantes y deberían priorizarse?"
4. "¿Qué pruebas se pueden dejar para después?"
5. "¿Qué tipos de pruebas se van a escribir? ¿De extremo a extremo? ¿De accesibilidad?"

Al responder estas preguntas obtengo información valiosa para comenzar lo que llamo el proceso creativo de escribir pruebas automatizadas.

Después inicio un proceso exploratorio de la aplicación (o funcionalidad) que se va a probar.

En ese momento, además de descubrir cómo se comporta actualmente la aplicación, también descubro casos extremos, que a veces se olvidan durante el desarrollo de la aplicación.

Así que, sin más preámbulos, abro el editor de código y empiezo a escribir un "esqueleto" 💀 de la suite de pruebas. Solo las descripciones de los casos de prueba, sin detalles de implementación.

Estructurando suites de pruebas con Cypress

En Cypress, los casos de prueba se organizan en una suite de pruebas.

La forma más común de definir una suite de pruebas es usando dos funciones distintas.

Son las funciones describe() e it() de mocha.

Reciben una cadena de texto como primer argumento y una función de callback como segundo argumento.

El primer argumento de describe es la descripción de la suite de pruebas (por ejemplo, 'Authentication', 'Products Search', 'Users List', etc.)

Los casos de prueba se definen dentro de la función de callback (su segundo argumento).

La función it() define un caso de prueba.

El primer argumento de it es la descripción del caso de prueba (por ejemplo, 'successfully logs in', 'searches for a nonexistent product', 'lists the first ten users', etc.)

Los detalles de implementación de la prueba van dentro de la función de callback (su segundo argumento).

Abajo hay un ejemplo del esqueleto de una suite de pruebas con un par de casos de prueba.

describe('Authentication', () => {
  it('successfully logs in', () => {
    // test implementation here.
  })

  it('successfully logs out', () => {
    // test implementation here.
  })
})

Ejercicio 🎯

Basándote en el proceso sugerido arriba, crea un "esqueleto" de las pruebas que consideres esenciales para garantizar que la aplicación Cypress Simulator funciona como se espera, dándole así al equipo la confianza de que, si todas las pruebas están en verde, se puede entregar a producción para su uso.

Muéstrale al mundo lo que aprendiste 🌎

Para mostrarle a tu red profesional lo que aprendiste en esta lección, publica lo siguiente en LinkedIn.

Estoy haciendo el curso Cypress Simulator con @Walmyr Lima e Silva Filho en la escuela @Talking About Testing, donde aprendí un proceso práctico de planificación de pruebas automatizadas que me ayuda a priorizar las pruebas más importantes y a tener algo concreto sobre lo cual trabajar. #TalkingAboutTesting #TATSchool #CypressSimulator #Cypress

👨‍🏫 No olvides mencionarme en tu publicación. Aquí está mi perfil de LinkedIn.