Cómo probamos los generadores de Varnip
Última actualización: 3 de noviembre de 2026. Esta página enumera lo que comprueban las pruebas de Varnip en cada generador, cuántos casos ejecutan, qué software lee los archivos de vuelta y qué no pueden demostrar las pruebas. Las cifras se leyeron del código de las pruebas el 14 de octubre de 2026, antes de que existiera la versión en español.
¿Cómo prueba Varnip sus generadores?
Varnip prueba cada generador creando archivos para entradas conocidas y leyéndolos de vuelta con un decodificador de software, zxing-wasm. Una prueba de lectura de vuelta solo se aprueba si el texto que sale es el texto que entró. Las líneas del código de barras y los módulos del código QR los dibuja un código distinto del decodificador, así que en ellos quien lee no es quien escribe; el Data Matrix es la excepción, como explica la sección de límites. Las pruebas de navegador dibujan archivos en los motores Chromium, Firefox y WebKit. Antes de cada publicación, un solo comando ejecuta todas las pruebas y las demás comprobaciones de la lista de abajo, y la publicación no sale si alguna falla.
¿Cómo se prueba el generador de código de barras?
El generador de código de barras se prueba dibujando cada formato en cada tamaño y resolución, y leyendo cada archivo de vuelta. El generador hace cuatro tipos de código de barras: Code 128, UPC-A, EAN-13 y EAN-8. La prueba dibuja cada uno en los tres tamaños del menú Tamaño (80%, 100% y 200% de la barra de 0.33 mm) y en dos resoluciones (300 y 600 dpi). Son 24 combinaciones en cada motor de navegador, es decir, 72 archivos PNG y 72 archivos SVG en total. Cada combinación da cuatro lecturas: el PNG y el SVG, cada uno con la opción “try harder” del decodificador activada y desactivada. Son 96 lecturas en cada navegador y 288 en total. El navegador dibuja el PNG en un canvas, como el tuyo; el SVG lo genera el código del generador en el navegador y una biblioteca de renderizado, Resvg, lo convierte en imagen para el decodificador.
¿Qué se mide en los archivos?
Además de leer cada archivo de vuelta, la prueba mide el archivo mismo: la resolución guardada en el PNG, píxeles enteros en cada barra, el ancho de barra de los formatos de comercio dentro del 80% al 200% de la barra de 0.33 mm, el rango de la referencia de símbolos EAN/UPC de GS1 Canada (2018, en inglés), los márgenes en blanco (zonas de silencio), el tamaño del SVG en milímetros y que el SVG no contiene elementos de texto.
¿Qué más se comprueba?
Las pruebas unitarias comprueban el dígito de control en tres números conocidos, rechazan un dígito de control incorrecto y nunca lo corrigen, y mantienen el texto dentro de la caja del símbolo en todos los formatos. También comprueban que un ZIP hecho por el escritor de ZIP de la página pase la prueba de integridad de unzip y de 7-Zip, y que el texto escrito nunca se convierta en marcado en la vista previa (cinco cadenas hostiles). La prueba de navegador de la página comprueba que los archivos que descarga la página se lean de vuelta en todos los formatos, que un lote de mil archivos SVG o de 100 archivos PNG salga completo, y que el PNG número 100 del ZIP se lea de vuelta. El 5 de octubre de 2026 también medimos el PDF que genera la impresión de Chromium: la regla de 50 mm midió 50.0 mm.
¿Las páginas de un solo formato se prueban igual?
Las páginas de Code 128, UPC y EAN-13 usan el mismo generador de código de barras, fijado en un formato, así que las pruebas anteriores cubren sus archivos. En cada una de las tres páginas, en Chromium, Firefox y WebKit, una prueba de navegador comprueba además que la página abra con su propio ejemplo y sin selector de formato, y que los archivos PNG y SVG que descarga, y un archivo de un ZIP de lote, se lean de vuelta con el decodificador de software. La página de código de barras y código QR se comprueba igual en las dos direcciones de su interruptor: cada herramienta descarga un archivo que se lee de vuelta, y la herramienta oculta no recibe ninguna parada de teclado.
¿Cómo se prueba el generador de código QR?
El generador de código QR se prueba generando códigos para textos de muestra, leyendo cada uno de vuelta y comprobando el nivel de corrección de errores que lleva. Un conjunto de 7 muestras (una dirección web, dígitos, mayúsculas con símbolos, texto con letras acentuadas, caracteres japoneses y emoji, una red WiFi, una tarjeta de contacto y un texto con espacios en ambos extremos) se genera en los cuatro niveles de corrección de errores, lo que da 28 códigos. Cada uno se convierte en imagen y se lee de vuelta, y la prueba falla a menos que el texto coincida exactamente y el decodificador indique el nivel elegido.
¿Qué agregan las pruebas de navegador?
En Chromium, Firefox y WebKit, la prueba crea archivos PNG para cuatro textos (una dirección web; un texto con acentos, caracteres japoneses y emoji; una red WiFi; y un texto largo) con dos niveles de corrección de errores y dos tamaños impresos (2 cm a 300 dpi y 5 cm a 600 dpi). Son 16 archivos PNG en cada navegador y 48 en total. Cada archivo se revisa de cinco maneras: el texto se lee de vuelta exactamente, el nivel se lee de vuelta como se eligió, los módulos son píxeles enteros y la imagen es cuadrada, la resolución está en el archivo, y el margen en blanco de arriba y de la izquierda mide al menos cuatro módulos. Una prueba unitaria mide ese margen en los cuatro lados, el margen que DENSO WAVE (2026, en inglés) dice que necesita un código QR.
¿Se leen de vuelta los diez tipos de código QR?
Los diez tipos se leen de vuelta, pero no todos desde la página. Para cinco tipos (Sitio web, WiFi, Texto, SMS y Ubicación), se leen de vuelta los archivos PNG y SVG que la página descarga en Chromium, Firefox y WebKit: 30 archivos. Los otros cinco tipos (Contacto, Correo, Teléfono, WhatsApp y Evento) se leen de vuelta en Node.js a partir del mismo código que construye su contenido, no desde el botón de descarga de la página del generador de código QR.
¿Cómo se prueban las entradas difíciles?
Los nombres de WiFi se prueban con 8 casos hostiles que usan los símbolos ; , : \ y la comilla doble dentro del nombre. El texto pasa por nuestras propias reimplementaciones de cómo Android y la biblioteca ZXing leen los códigos WiFi, y el constructor debe avisar exactamente en los casos en que un lector antiguo de Android falla. Las tarjetas de contacto (vCard) y los eventos de calendario se comprueban con 16 y 12 casos etiquetados, entre ellos una línea de fecha escrita en la descripción de un evento, que debe seguir siendo texto y nunca convertirse en una segunda fecha de inicio, y la hora que el horario de verano repite. Una contraseña de WiFi nunca acaba en un nombre de archivo.
¿Se prueban las páginas de WiFi, ubicación y vCard?
Sí: en las páginas de WiFi, ubicación y vCard, en Chromium, Firefox y WebKit, una prueba de navegador comprueba que la página abra con su propio ejemplo y no muestre ningún otro tipo de código, que los archivos PNG y SVG que descarga se lean de vuelta como el ejemplo, y que, después de editar un campo, los archivos nuevos se lean de vuelta tal como se escribió. La misma prueba escribe en cada una de estas páginas y comprueba que lo escrito no aparezca en ninguna solicitud, ningún conteo ni ningún nombre de archivo.
¿Cómo se prueba el generador de GS1 Digital Link?
El generador de GS1 Digital Link se prueba con 33 casos: 21 entradas que deben producir una dirección exacta y 12 que deben rechazarse con un motivo. Cada resultado esperado viene de GS1: de los ejemplos de su estándar de sintaxis de URI, de las pruebas del motor de código abierto de GS1 o de ejecutar ese motor. Los 12 rechazos cubren un dígito de control incorrecto, un lote que es demasiado largo o tiene un espacio o un carácter prohibido, una fecha que no existe o que no tiene seis dígitos, y un lote sin GTIN. Cada rechazo aparece bajo el campo al que corresponde. El formato de la dirección se describe en el estándar de sintaxis de URI de GS1 Digital Link (2026, en inglés).
¿Cómo se leen de vuelta los códigos?
En 4 de los casos, la dirección se genera como código QR y se lee de vuelta como texto simple. En 4 direcciones se genera el Data Matrix, se dibuja como SVG, se convierte en imagen y se lee de vuelta como el mismo texto. La prueba del Data Matrix también comprueba que el símbolo sea cuadrado y que escribir dos veces la misma dirección dé el mismo símbolo. Para 3 direcciones de muestra en los dos tipos de código, con el tamaño impreso predeterminado de la página, 2 cm a 600 dpi, cada módulo se mantiene entre 0.396 y 0.990 mm, el rango de la hoja informativa de GS1 Nueva Zelanda sobre códigos de barras 2D (2025, en inglés). En los tres navegadores, los archivos SVG del código QR y del Data Matrix que descarga la página se leen de vuelta como la dirección que se muestra en pantalla.
¿Y la privacidad de lo que escribes?
La prueba de la página escribe un GTIN, un lote, un número de serie, una fecha y un dominio, y comprueba que ninguno aparezca en ninguna solicitud de la página, y que ninguna solicitud salga del servidor local de pruebas.
¿Cómo se prueba el generador de Data Matrix?
El generador de Data Matrix se prueba generando cuatro textos de muestra como Data Matrix y leyendo cada uno de vuelta: una dirección web, un texto con un acento y un emoji, un número de lote con una barra y un texto de 1500 letras. Cada símbolo se dibuja como SVG, se convierte en imagen y lo lee de vuelta el decodificador de software, y la prueba falla a menos que el texto coincida exactamente, el decodificador indique un Data Matrix simple y el margen en blanco mida un módulo. Un texto demasiado largo para un Data Matrix debe rechazarse con las palabras “demasiado largo”. En Chromium, Firefox y WebKit, una prueba de navegador comprueba que la página abra con su ejemplo ya dibujado, que los archivos PNG y SVG que descarga se lean de vuelta, que no haya control de protección contra daños y que los tamaños impresos sean 2, 3, 5 y 10 cm. El decodificador de software no es un teléfono ni un escáner: escanea un código impreso antes de imprimir muchos.
¿Qué se ejecuta antes de cada publicación?
Antes de cada publicación, un solo comando ejecuta estas comprobaciones en orden y se detiene en la primera que falla.
- La versión de Node.js y el archivo de bloqueo son los esperados.
- Los archivos de borde del sitio (encabezados de respuesta y redirecciones) coinciden con el ajuste de indexación.
- La comprobación de tipos y la construcción del sitio.
- Todos los archivos de pruebas: las pruebas unitarias, las pruebas de navegador y las pruebas de las páginas construidas.
- Una comprobación de que el JavaScript construido funciona en los navegadores que Varnip admite (ES2021).
- Presupuestos de tamaño: ninguna página entrega más script que su presupuesto.
- Licencias: toda tipografía y toda dependencia que se entrega está registrada con su licencia.
- Una búsqueda de secretos, como tokens de acceso, en los archivos y en todo el historial.
- Una auditoría de seguridad de las dependencias, en la que todo aviso de gravedad alta o crítica debe figurar con un motivo y una fecha de revisión.
Las pruebas de las páginas construidas comprueban, entre otras cosas, que toda página tenga una dirección canónica y datos estructurados, que el mapa del sitio lleve una fecha para cada página, que ningún script o estilo incrustado sea bloqueado por la política de seguridad de contenido, y que el Worker que cuenta las visitas guarde solo una lista cerrada de campos y no registre las visitas de la Unión Europea ni del Espacio Económico Europeo. El 14 de octubre de 2026, los nueve archivos de pruebas que no necesitan navegador tenían 135 pruebas, y las 135 se aprobaron.
¿Qué no cubren las pruebas?
Las pruebas tienen límites, y esta página los indica para que puedas juzgar los resultados.
- El Data Matrix lo genera y lo lee la misma biblioteca (zxing-wasm). Su lectura de vuelta demuestra que este decodificador puede leer el archivo, no que dos decodificadores independientes coincidan. Las lecturas de vuelta del código QR y del código de barras no tienen este límite.
- Los analizadores que hacen el papel del lector de códigos WiFi de Android, y de los lectores de códigos WiFi, de correo y de mensaje de texto de la biblioteca ZXing, son reimplementaciones nuestras, no los programas originales.
- Las pruebas no usaron la cámara de un teléfono, un escáner de tienda ni una etiqueta impresa. Fuera de las pruebas, en un teléfono Android, una aplicación lectora leyó un PNG de Code 128 descargado. Escanea un código impreso antes de imprimir muchos.
- Las pruebas de navegador ejecutan los motores Chromium, Firefox y WebKit que instala la herramienta de pruebas Playwright, en un equipo de pruebas, no en los navegadores de tu teléfono; no se usó ningún iPhone real.
- El generador de GS1 Digital Link no consulta id.gs1.org ni tu dominio. Comprueba el dígito de control del GTIN, que no es lo mismo que comprobar que un GTIN está registrado o te pertenece. El 14 de octubre de 2026, nuestra propia comprobación encontró que el GTIN de ejemplo de GS1, 09520123456788, respondía “Not Found” en id.gs1.org.
- El tamaño de una impresión depende del cuadro de diálogo de impresión. La prueba de impresión midió el PDF que genera Chromium, no el papel de una impresora, así que comprueba la regla de 50 mm en tu propia impresión.
- Las cifras y las fechas de esta página vienen de las pruebas del 14 de octubre de 2026, que abren páginas en inglés; ninguna prueba de navegador ha abierto todavía una página en español.
¿Cómo reporto un error en esta página?
Puedes escribir un correo a hello@varnip.com. Si una prueba descrita aquí no coincide con lo que encuentras en un generador, o tienes un código que no se lee, envía la entrada y el tipo de archivo, y la única persona que hace Varnip lo leerá. Consulta la página Acerca de Varnip para saber quién es.