Saltar al contenido

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:

JS
// 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.