Pruebas desde el móvil, criterios de cobertura incluidos
Seis niveles de pruebas, criterios de cobertura de sentencias a MC/DC y por qué tener los resultados en el móvil es una ventaja.
La pestaña Proyecto → Pruebas no es solo una lista de lo que falla. Es el sitio donde encargas pruebas, lees su historial y vas de un caso que falla a lo que en realidad comprueba, y todo desde el móvil, sin una sola línea de prompt.
Niveles
Las pruebas están divididas en seis niveles: unitarias, de integración, de sistema, E2E, rendimiento de la interfaz y rendimiento del backend. Se cambian arriba y cada uno guarda su propio historial de Ejecuciones.
Esa división no es cosmética. Una prueba unitaria que falla significa algo distinto de un E2E que falla, y cuando ves las dos en una sola lista pierdes justo la información por la que existen los niveles.
Criterios de cobertura: y por qué, en realidad
Cuando encargas pruebas con la frase «escribe pruebas», te dan pruebas. La cuestión es qué comprueban, y a eso nadie tiene respuesta hasta que algo se cae en producción.
Un criterio de cobertura es una regla que dice cuándo hay suficientes pruebas. No es un porcentaje; es una frase que se puede comprobar:
- Cobertura de sentencias
- Cada sentencia se ejecuta al menos una vez. Lo más barato y lo más débil: el código se ha ejecutado, pero de sus ramas no dice nada.
- Cobertura de ramas
- Cada condición sale una vez verdadera y una vez falsa. Aquí es donde las pruebas empiezan a encontrar errores.
- MC/DC
- En cada subcondición se demuestra que ella sola cambia el resultado. Caro, pero en condiciones compuestas es la única manera de descubrir que una de ellas está de más.
- Pair-wise
- Cada par de valores de características distintas se encuentra en al menos una prueba. Una fracción de las combinaciones, la mayoría de los errores.
En la aplicación eliges el criterio al encargar las pruebas y ves lo exigente que es, antes de que el Agente empiece a trabajar. Esa es la diferencia respecto a «escribe pruebas»: sabes qué vas a recibir y el Agente sabe cuándo parar.
Deja que el Agente te prepare el resumen de los criterios para tu proyecto. Añadirá en cada uno lo exigente que es precisamente aquí: en un analizador es una cosa y en un formulario otra.
Por qué tenerlo en el móvil es una ventaja
- Los resultados se leen también sin conexión. Las Ejecuciones están descargadas, así que puedes rebuscar en ellas hasta en un avión.
- De un caso que falla hay un enlace a su descripción en la documentación y a una captura del momento de la caída. No a cien líneas de registro.
- El historial a lo largo de las Ejecuciones revela una prueba inestable: la que pasa una vez y la siguiente no. En el terminal te acuerdas de ella, aquí se ve.
- Los valores medidos en las pruebas de rendimiento tienen un recorrido a lo largo de las Ejecuciones. Un número no dice nada de una medición, la dirección sí.
- Encargar más pruebas son unos cuantos toques, no escribir un prompt. Se elige el nivel y el criterio, el resto lo hace el Agente.
De dónde salen los resultados
La aplicación lee JUnit XML, es decir, el formato que casi cualquier herramienta de pruebas sabe escupir. El Agente lo escribe en el proyecto y el móvil lo descarga con el espejo: ningún servicio en medio, ninguna subida a ninguna parte.
La forma en la que se escriben los resultados la fija un skill de aplicación. Los skills se meten en el proyecto desde la pestaña Proyecto, sección Skills de aplicación; sin ellos verás solo lo que ya hay en el proyecto.
¿Se ha atascado en otro sitio distinto de lo que hay aquí? Escribe a support@coden-app.com.