Probar el lado web
Componentes, estado e interacción: qué se prueba del frontend de una aplicación de Tauri, y cómo se sustituye el puente para no necesitar el core.
Qué merece prueba aquí
La quinta fila es un diagnóstico: si tu frontend tiene lógica de negocio que merece prueba, el problema no es que falten pruebas — es que esa lógica debería estar abajo.
Sustituir el puente
Lo que hace que las pruebas del frontend no necesiten un core:
// un doble del puente: cada comando devuelve lo que la prueba digaconst respuestas = new Map();window.__TAURI_INTERNALS__ = { invoke: async (cmd, args) => { const r = respuestas.get(cmd); if (!r) throw new Error(`comando no simulado: ${cmd}`); return typeof r === 'function' ? r(args) : r; },};Tres cosas que este doble permite y que con un core real cuestan:
- Provocar errores. Que un comando falle con cada variante del nivel 16.
- Provocar lentitud. Para probar los estados de carga.
- Y comprobar qué se llamó. Con qué argumentos y cuántas veces — que es la traza del nivel 55.1 convertida en aserción.
La tercera es la más útil: una prueba que comprueba que pulsar un botón llama a un comando con los argumentos correctos cubre el contrato con el core sin necesitarlo.
Los estados que nunca se ven
Y la razón principal para probar el frontend en escritorio:
- Cargando, que en desarrollo dura milisegundos y en la máquina de un usuario con datos reales, segundos.
- Vacío, que solo se ve la primera vez y es la primera impresión. Nivel 49.4.
- Error, con cada variante distinguible.
- Y sin conexión. Nivel 48.3.
Los cuatro se prueban trivialmente con el doble y no se ven casi nunca desarrollando — que es la definición de lo que merece prueba automática.
Calibrar el esfuerzo
Y una advertencia sobre traer costumbres de la web:
- En una aplicación web, el frontend es la aplicación: tiene el estado, la lógica y la mayor parte del riesgo, y se prueba mucho.
- Aquí no. Nivel 53.1: el frontend es una capa de presentación fina, y el riesgo está abajo.
La proporción correcta: bastantes menos pruebas de frontend de las que tendría una aplicación web equivalente, y más pruebas de core. Si tu suite tiene más pruebas arriba que abajo, merece preguntarse si el reparto de responsabilidades es el que crees.