Que una persona pueda iniciar sesión no demuestra que esté autorizada para consultar o modificar cada dato de la aplicación. La autenticación identifica al usuario; la autorización decide qué puede hacer, sobre qué recurso y bajo qué condiciones. Una ruta puede exigir una sesión válida y, aun así, permitir que alguien lea el pedido de otra cuenta si no se comprueba la relación entre usuario y recurso.
Las pruebas de autorización en PHP deben verificar ese límite desde los puntos de entrada que usa la aplicación: por ejemplo, una petición HTTP a una ruta web o a una API. El objetivo no es probar cómo implementa sus políticas un framework, sino confirmar el comportamiento observable: quién puede hacer qué, cuándo se rechaza la solicitud y qué datos permanecen intactos.
Traducir las reglas de acceso en una matriz
Antes de escribir pruebas, expresa las reglas con cuatro elementos: actor, acción, recurso y contexto. El contexto incluye condiciones que modifican el permiso, como pertenecer a la misma organización, ser propietario del registro o tener un estado determinado. Esta estructura evita reducir la autorización a una lista de roles.
- Actor: usuario anónimo, miembro, responsable o administrador.
- Acción: consultar, crear, editar, eliminar o aprobar.
- Recurso: un pedido, documento, cuenta u otro objeto protegido.
- Contexto: propietario, organización, estado del recurso o relación vigente.
Por ejemplo, una regla puede permitir que un miembro consulte sus propios pedidos, mientras que un responsable consulta los de su organización. Un administrador podría tener acceso más amplio, sujeto a las reglas reales del producto. La matriz convierte cada frase de negocio en casos comprobables y hace visibles las combinaciones que faltan.
No hace falta probar todas las permutaciones imaginables. Prioriza los límites de confianza: un usuario sin sesión, dos usuarios de la misma organización, usuarios de organizaciones distintas, una persona con un rol privilegiado y un recurso que no le pertenece. Añade contextos especiales que cambien la decisión, como un pedido archivado si sus permisos difieren de los de uno activo.
Preparar escenarios de integración representativos
Prepara los datos de forma explícita y pequeña. Una prueba típica puede crear dos organizaciones, un usuario en cada una y un recurso asociado a una de ellas. Luego autentica como el usuario que intenta acceder y realiza una petición a la ruta pública de la aplicación, usando el identificador del recurso. Así se ejercitan conjuntamente la entrada, la autenticación, la autorización y la respuesta.
Para cada regla importante, incluye al menos un caso permitido y uno denegado. Si el usuario propietario puede editar un recurso, comprueba que la edición autorizada funciona y que otro usuario no puede repetirla. Un caso positivo es esencial: una suite que solo espera rechazos podría pasar aunque la aplicación bloqueara también a quien sí tiene permiso.
Comprueba además el recurso inexistente. La respuesta ante un identificador desconocido puede ser distinta de la respuesta ante uno existente sin permiso. En algunas aplicaciones se utiliza una respuesta de no encontrado para no revelar la existencia del recurso; en otras, se comunica que el acceso está prohibido. La prueba debe reflejar la política deliberada del producto, no imponer una convención universal.
Utiliza fábricas, constructores de fixtures o helpers de prueba que produzcan estados válidos y legibles. Evita depender de identificadores fijos, del orden de ejecución o de datos compartidos que otra prueba pueda modificar. Si la persistencia forma parte del comportamiento que quieres comprobar, verifica el resultado en la base de datos usando las herramientas habituales del proyecto; no asumas que una respuesta de éxito garantiza por sí sola el estado correcto.
Probar aislamiento entre usuarios y organizaciones
El aislamiento merece casos propios porque los errores suelen aparecer al cambiar un identificador en la URL o el cuerpo de la petición. Crea un recurso de una cuenta y solicita consultarlo, editarlo o eliminarlo desde otra identidad. Repite la comprobación entre organizaciones cuando la aplicación tenga ámbitos de datos por empresa. Para operaciones críticas, prueba cada acción: que una lectura esté protegida no demuestra que también lo estén la descarga, la exportación o la actualización.
Para no duplicar toda la suite, comparte la preparación común y parametriza únicamente las dimensiones que expresan la regla. Por ejemplo, una lista de pares actor-recurso puede definir qué combinaciones se permiten. Mantén los nombres de los casos concretos: “miembro de otra organización no puede editar el pedido” explica más que un conjunto opaco de valores booleanos. Separa los escenarios cuando el método, la ruta o los efectos esperados sean diferentes.
Evita probar cada combinación de roles con cada recurso si muchas no representan reglas distintas. En su lugar, identifica equivalencias justificadas y conserva casos explícitos para excepciones y fronteras. Si hay roles jerárquicos, no presupongas que uno hereda automáticamente todos los permisos de otro: verifica la regla efectiva que define el producto.
Verificar respuestas y efectos secundarios
En un rechazo, comprueba tanto la respuesta como que la operación protegida no se haya ejecutado. Según la interfaz, la respuesta puede ser una redirección, un estado de acceso no autorizado o prohibido, o una respuesta de recurso no encontrado. Comprueba el contrato relevante —estado, formato y, cuando importe, mensaje— sin acoplar la prueba a detalles de presentación innecesarios.
Para una actualización denegada, verifica que los campos sensibles siguen igual. Para una eliminación, que el registro continúa disponible. Para una operación que genera una factura, una notificación o un evento, comprueba que tampoco se haya producido ese efecto. Las aserciones deben cubrir los efectos importantes para el negocio, no solo el código HTTP.
Una petición no autorizada tampoco debe permitir cambios parciales. Si el flujo hace varias operaciones, verifica que el rechazo ocurre antes de las mutaciones o que la transacción deja el sistema en un estado coherente. No es necesario inspeccionar métodos privados para demostrarlo: observa la respuesta y los datos o efectos persistidos.
Mantener pruebas resistentes a cambios de implementación
Las pruebas de integración deben pasar por una interfaz estable de la aplicación, como una ruta y una petición con la identidad autenticada mediante los mecanismos de prueba disponibles. Evita llamar directamente a una clase interna de políticas si lo que quieres validar es el acceso real a un recurso: hacerlo podría dejar sin cubrir el registro de la ruta, el middleware o la forma en que se carga el objeto.
A la vez, no conviertas la suite en una réplica de toda la aplicación. Prueba el contrato de autorización en puntos representativos y reserva pruebas unitarias para reglas puras que necesiten muchos casos de contexto. La combinación ayuda a localizar fallos: una prueba de regla puede aislar una condición, mientras que la de integración confirma que esa regla protege el flujo expuesto.
Cuando cambien roles, rutas o políticas, revisa la matriz antes de modificar expectativas. Una prueba que se actualiza solo para aceptar el nuevo resultado puede ocultar una ampliación accidental de permisos. Registra por qué cambió la regla, identifica qué actores ganan o pierden acceso y añade casos que protejan las nuevas fronteras.
Lista de comprobación para revisar un cambio
- ¿Están definidos actor, acción, recurso y contexto?
- ¿Hay al menos un escenario permitido y uno denegado para la regla afectada?
- ¿Se prueba el acceso entre usuarios o ámbitos de datos cuando corresponda?
- ¿Se cubren recurso inexistente y la política elegida para no revelar información?
- ¿La petición pasa por el punto de entrada que debe estar protegido?
- ¿Se verifica que un rechazo no cambia datos ni genera efectos secundarios?
- ¿Los datos de prueba son aislados, legibles y reproducibles?
- ¿Las expectativas reflejan una decisión de producto y no un detalle accidental del framework?
Una suite útil no demuestra que “hay permisos” en abstracto: demuestra que las combinaciones relevantes funcionan y que las no autorizadas no cruzan el límite. Mantener esa matriz junto a pruebas de integración concretas facilita revisar cambios de acceso sin atar la seguridad a una implementación interna específica.
