Probar el lado de Rust
La base de la pirámide: qué se prueba sin arrancar la aplicación, cómo se organizan esas pruebas, y por qué son las que más valen en una app de escritorio.
Qué se prueba sin arrancar nada
Seis capas, todas probables en milisegundos, y todas ya diseñadas para serlo por las decisiones de las fases anteriores.
Los dobles que valen la pena
El cuarto es el que menos gente hace y el que más tiempo ahorra: probar que un testigo caduca a los treinta días no puede tardar treinta días, y con el reloj inyectado tarda un milisegundo.
Qué merece prueba
Y qué no, para no escribir pruebas por escribirlas:
- Sí: la lógica de negocio, las operaciones compuestas con transacciones, los caminos de error, las migraciones, y todo lo que el temario ha marcado como «se olvida siempre».
- No: envoltorios de una línea, código que solo llama a otra cosa, y los comandos finos del nivel 54.4 —que por diseño no tienen lógica que probar—.
- Y con cuidado: lo que depende de la plataforma. Nivel 71.2.
La regla útil: prueba lo que podría estar mal sin que nadie lo note. Un envoltorio roto se ve en cuanto se usa; una migración con un caso límite mal resuelto, no.
Por qué valen especialmente aquí
Y el argumento que cierra el nivel:
- No puedes mirar la máquina del usuario. Nivel 43.5: no hay servidor al que asomarse.
- Corregir tarda. Fase XI: horas en escritorio, días en móvil.
- Y los fallos que importan son de camino de error, que es lo que las pruebas cubren mejor y el uso manual peor.
En un servicio web, una prueba que falta se paga con un incidente que se corrige en minutos. Aquí se paga con datos perdidos en una máquina ajena.