Evitando Falsos Positivos: Fortaleciendo Tests de Reglas de Almacenamiento

Un test que pasa puede ser tan engañoso como uno que falla si lo hace por la razón equivocada. En el desarrollo de TuTiendaWeb, nos encontramos con un escenario clásico donde la aparente "victoria" de un test ocultaba una debilidad subyacente en nuestras reglas de seguridad de almacenamiento.

El Problema: Un 404 Disfrazado de Denegación

Estábamos probando una regla de seguridad de Storage del tipo "catch-all" – es decir, una regla diseñada para denegar el acceso anónimo a objetos en una ruta específica. La prueba consistía en intentar leer un objeto en esa ruta y esperar un fallo (assertFails). Sin embargo, el objeto que el test intentaba leer no existía. Esto planteó un problema crítico:

Cuando un cliente intenta leer un objeto inexistente, el sistema de almacenamiento responde con un error 404 Not Found. Nuestro test, que simplemente verificaba si la operación fallaba, interpretaba este 404 como un éxito en la denegación de la regla. El test pasaba, pero no porque la regla de seguridad estuviera denegando explícitamente el acceso, sino porque el objeto ni siquiera estaba allí para ser accedido.

Esto nos daba una falsa sensación de seguridad, ya que la regla podría estar mal configurada o ausente, y el test seguiría "pasando" gracias a un error de 404.

La Solución: Sembrar el Objeto para la Prueba

Para asegurar que la prueba realmente validara la denegación por parte de la regla de seguridad y no por una falta de existencia del objeto, implementamos un paso crucial: sembrar un objeto dummy antes de intentar leerlo.

Así es como abordamos la mejora en TypeScript:

import { getStorage, ref, uploadBytes, getDownloadURL } from 'firebase/storage';
import { assertFails, assertSucceeds } from '@firebase/testing'; // Ejemplo de librería de testing

const storage = getStorage(); // Inicializar Storage
const rulesDisabledPath = 'rules-disabled/dummy.txt';
const dummyContent = new Blob(['contenido de prueba'], { type: 'text/plain' });

// 1. Sembrar el objeto dummy para asegurar su existencia
// Esto garantiza que cualquier fallo posterior será por la regla, no por 404.
await assertSucceeds(uploadBytes(ref(storage, rulesDisabledPath), dummyContent));

// 2. Ahora, intentar leerlo de forma anónima.
// Esperamos que falle debido a la regla de seguridad (PERMISSION_DENIED).
await assertFails(getDownloadURL(ref(storage, rulesDisabledPath)));

// Si este test pasa, significa que la regla de 'catch-all' está funcionando correctamente
// y deniega el acceso a un objeto existente.

Al "sembrar" un pequeño archivo (dummy.txt) en la ruta rules-disabled antes de ejecutar la prueba de lectura anónima, nos aseguramos de que el objeto exista. Si la prueba de lectura assertFails pasa ahora, sabemos con certeza que el fallo proviene de una denegación explícita de la regla de seguridad (PERMISSION_DENIED), y no de un 404.

La Lección Aprendida

Esta experiencia subraya la importancia de diseñar tests que validen la causa raíz del comportamiento esperado. Es fácil caer en la trampa de un test que pasa, pero la verdadera robustez viene de asegurar que pasa por la razón correcta. Para reglas de seguridad, esto significa eliminar ambigüedades y forzar al sistema a ejercitar la lógica de las reglas, no simplemente su capacidad de encontrar o no un recurso.

Toma de acción: Siempre que pruebes denegaciones de acceso a recursos, asegúrate de que el recurso en cuestión exista antes de la prueba para validar la lógica de seguridad y no meramente la ausencia del recurso.

Generated with Gitvlg.com