Un test que rompe la compilación si escribo mal la historia.

Cuando empecé Tamarán tenía claro el objetivo: que un profesor de Primaria pudiera abrir el navegador y dar una clase sobre la vida en un poblado de Gáldar sin preparar nada. Lo que no tenía tan claro era hasta qué punto la parte difícil no iba a ser el código.

El error que estuve a punto de cometer

En mis primeras notas escribí «guanches» para referirme a los habitantes del poblado. Es lo que dice mucha gente en Canarias, lo que aparece en camisetas y en nombres de bares. Y está mal: los guanches eran los habitantes de Tenerife. En Gran Canaria hablamos de los antiguos canarios.

En una conversación de bar es una imprecisión sin más. En un material que va a usarse en un aula, es exactamente el mecanismo por el que un error se perpetúa una generación más. Y desde el punto de vista del producto es la forma más rápida de que un docente cierre la pestaña: si me equivoco en eso, ¿por qué se iba a fiar del resto?

Una fuente de verdad, y solo una

Lo primero fue dejar de improvisar. Todo el contenido histórico del juego —nombres, oficios, alimentos, vivienda, vocabulario— sale de un dossier documentado que mantengo aparte del código. La regla que me impuse es simple: si un dato no está en el dossier, no entra en el juego, por bien que quede en una escena.

Escribir «la regla» en un documento no sirve de nada si depende de que yo me acuerde a las dos de la mañana.

Automatizar el criterio

Por eso la regla acabó siendo una prueba automática. Un test recorre los textos del juego y falla si encuentra terminología vetada, con lo que la compilación se detiene y el error no puede llegar a producción:

import { describe, it, expect } from 'vitest';
import { textosDelJuego } from '../src/contenido';

// Términos incorrectos para Gran Canaria y su alternativa correcta.
const VETADOS = [
  { mal: /guanche/i, bien: 'antiguos canarios' },
];

describe('rigor histórico', () => {
  it('no usa terminología incorrecta', () => {
    const fallos = [];

    for (const [clave, texto] of Object.entries(textosDelJuego)) {
      for (const { mal, bien } of VETADOS) {
        if (mal.test(texto)) fallos.push(clave + ': debe decir "' + bien + '"');
      }
    }

    expect(fallos, fallos.join('\n')).toHaveLength(0);
  });
});

No es un test sofisticado: es una expresión regular y una lista. Pero convierte una intención —«hay que ser riguroso»— en algo que el proyecto verifica solo, cada vez, sin depender de mi memoria ni de mi cansancio.

El mismo criterio con las imágenes

La otra decisión incómoda fue la de los recursos gráficos. Encontré material precioso en bancos de imágenes y repositorios, pero con licencias que no permitían un uso comercial futuro. Como quiero poder distribuir Tamarán sin sustos, la norma es igual de estricta: solo material con licencia CC0 o arte propio. El resto del pixel art lo estoy dibujando yo, que es más lento y bastante más divertido.

Lo que me llevo

• Los criterios de calidad no técnicos también se pueden automatizar. Terminología, licencias, accesibilidad: si se puede describir, se puede comprobar.
• Un test que falla es más barato que una corrección pública. Sobre todo cuando el usuario final tiene diez años.
• Documentar la fuente antes de escribir el contenido evita desmontar una escena entera dos semanas después.