Probar lo que depende del sistema

Ficheros y directorios

La tercera fila es la decisión de diseño que lo hace posible: si tu código llama directamente a la API de rutas de Tauri, no se puede probar sin Tauri. Si recibe el directorio como argumento, sí — y en producción se lo da quien lo construye.

Procesos

Lo del nivel 47.1, con su forma de probar:

• Un binario de prueba propio, pequeño, que hace lo que le pidas por argumentos: escribir mucho, tardar, fallar con cierto código, no terminar.
• Con él se prueban los cuatro comportamientos del nivel 45.1: leer la salida, el código de retorno, el límite de tiempo y la terminación.
• Y se compila con las pruebas, así que está siempre y en todas las plataformas.

Es media hora de trabajo y convierte el helper de procesos en algo verificable — que sin eso solo se prueba a mano con herramientas del sistema que difieren entre plataformas.

Comportamiento por plataforma

Y el caso incómodo:

Y la tercera es lo que cierra: sin ejecutar en todas, una prueba condicionada a una plataforma solo se ejecuta cuando alguien compila ahí.

Las pruebas frágiles

Y las cuatro formas de escribir una prueba que falla sin motivo:

• Depender del orden entre pruebas, que suelen ejecutarse en paralelo.
• Depender del reloj real. Nivel 71.1: se inyecta.
• Depender de la red, aunque sea local. Un servidor falso en un puerto fijo choca si dos pruebas corren a la vez.
• Y depender de recursos compartidos: el mismo fichero, el mismo directorio, el mismo puerto.

Las cuatro se resuelven igual: cada prueba con lo suyo, creado y destruido por ella.