Indicadores de funcionalidades de PrestaShop 9.2: probar ambas rutas del Back Office
Un indicador de funcionalidad cambia la ruta de código que se está probando. Dos testers pueden ejecutar la misma versión de PrestaShop, abrir lo que parece la misma página del Back Office y aun así probar implementaciones distintas. Sin un inventario de indicadores, sus resultados pueden parecer contradictorios.
En el anuncio de la versión 9.2 RC1, PrestaShop dirige a los testers a Parámetros avanzados → Funciones nuevas y experimentales. Use esa página para inspeccionar los interruptores disponibles en la candidata instalada. A fecha de 26 de septiembre de 2026, la versión que los contiene sigue siendo software preliminar. Orientaciones oficiales de RC1 sobre indicadores de funcionalidades.
Este artículo trata del uso y las pruebas de indicadores. El artículo complementario sobre migración a Symfony aborda el código de extensiones que hay detrás de las páginas migradas.
Cuando un interruptor selecciona una página administrativa migrada, incluya las comprobaciones de migración a Symfony para desarrolladores de módulos para que el test siga el contrato real de la extensión.
Distinguir disponibilidad, madurez y activación
A menudo se condensan tres preguntas distintas en «¿Está lista la funcionalidad?». ¿La implementación está presente en este paquete? ¿Qué madurez le asigna el proyecto? ¿Está habilitada en esta instalación?
Una funcionalidad marcada como estable dentro de un sistema de indicadores puede seguir entregándose en una versión candidata. Una capacidad experimental puede seguir siendo opcional incluso después de que una versión del núcleo se vuelva estable. Un módulo instalado también puede exponer comportamientos sujetos a su propia configuración.
En el registro de un test, conserve los tres hechos. «Países probado» está incompleto si la ruta antigua y la migrada pueden coexistir. «Probado con la ruta migrada de Países habilitada en esta compilación candidata» identifica un entorno significativo.
No deduzca el estado de un indicador a partir de una captura. Una página puede ser visualmente similar después de migrarse. Lea la configuración y, cuando corresponda, verifique la ruta o implementación activa mediante los diagnósticos compatibles de la aplicación instalada.
Del mismo modo, no suponga que deshabilitar una funcionalidad deshará los cambios de datos realizados mientras estaba activa. Un interruptor selecciona un comportamiento; no es automáticamente una reversión de transacción ni una bajada de versión de la base de datos.
Saber qué rutas debe cubrir el test
Las notas para desarrolladores de la versión 9.2 identifican estos interruptores de páginas migradas:
| Página | Indicador documentado |
|---|---|
| Países | country |
| Devolución de mercancías | merchandise_return |
| Enlazar un módulo | hook_module_v2 |
| Acceso rápido | quick_access |
| Traducciones del cuerpo de los correos | email_body_translation |
| Reglas fiscales | tax_rules_group |
Estos nombres proceden de la documentación específica de la versión, cuyo párrafo sobre el estado de publicación todavía conserva una redacción anterior sobre la beta. Use el anuncio RC más reciente para el estado de la versión y verifique los interruptores en la compilación exacta instalada. Referencia de indicadores de la versión 9.2.
La tabla no promete que todos los indicadores permanezcan indefinidamente. Un indicador puede retirarse cuando una ruta pasa a ser la implementación estándar. No codifique de forma rígida una política de soporte permanente basada en la disponibilidad continua de un interruptor antiguo.
Para cada página que su equipo personalice, identifique si debe probar la ruta actual, la alternativa o ambas. Probar interruptores irrelevantes añade ruido. Omitir un interruptor que controla una página personalizada deja un vacío real de cobertura.
Capturar una base de referencia antes de cambiar nada
Registre las versiones del núcleo, módulos y tema, el contexto actual de tienda y el conjunto completo de estados de los indicadores pertinentes. Tome una instantánea de prueba restaurable antes de operaciones que puedan modificar datos persistentes.
Use un pequeño conjunto de prueba diseñado según la finalidad de la página. Para Países, podría ser una entrada sintética de configuración y el comportamiento de la tienda que depende de ella. Para Acceso rápido, podría ser un enlace de prueba y un empleado con permisos restringidos. El conjunto debe hacer visible el resultado esperado.
Cambie un interruptor pertinente y repita después la misma operación de negocio. Mantenga constantes las demás variables cuando sea posible. Si habilita varias capacidades, actualiza módulos y cambia permisos al mismo tiempo, un fallo ya no podrá atribuirse claramente.
Una nota de referencia también debe describir el estado de la sesión. Las pestañas abiertas y los recursos en caché pueden no representar la ruta recién seleccionada. Empiece la comparación con una navegación nueva y confirme qué implementación está activa antes de recopilar pruebas.
No confíe en la memoria para el ajuste original. El inventario es lo que permite a otro tester reproducir la comparación más adelante.
Comparar el comportamiento de negocio entre ambas rutas
Para un formulario administrativo, pruebe la carga inicial, un fallo de validación, un guardado correcto y la recarga. Para una cuadrícula, pruebe la lista pertinente, los filtros y las acciones de fila. Para la navegación, pruebe el enlace y los permisos del empleado que lo sigue.
La comprobación deseada suele ser un invariante de negocio: se guarda el mismo ajuste previsto con el mismo alcance, o la misma operación autorizada afecta al mismo registro. La igualdad a nivel de píxel no es necesariamente el objetivo de una migración.
Incluya un caso negativo. Un empleado sin permiso de escritura no debe obtenerlo en la ruta alternativa. Un valor no válido no debe pasar a aceptarse solo porque cambie el renderizador del formulario. Un guardado específico de una tienda no debe ampliarse a todas.
Use un registro comparativo:
| Caso | Ruta de referencia | Ruta migrada | Decisión |
|---|---|---|---|
| Guardar datos de prueba válidos | Resultado guardado | Resultado guardado | Equivalente o diferencia explicada |
| Rechazar datos de prueba no válidos | Comportamiento de validación | Comportamiento de validación | Sin persistencia no deseada |
| Empleado restringido | Operaciones permitidas | Operaciones permitidas | Límite de permisos conservado |
| Recargar después de guardar | Valor mostrado y alcance | Valor mostrado y alcance | Persistencia confirmada |
Una diferencia puede ser intencionada. Registre por qué es aceptable en lugar de obligar a la nueva página a imitar un defecto antiguo o una personalización indocumentada.
Tratar el retorno a la ruta anterior como un experimento separado
Un error habitual es suponer que, si falla una ruta nueva, desactivar su indicador restaura por completo el entorno antiguo. La ruta anterior puede volver a activarse, pero los registros editados durante el experimento pueden seguir modificados.
Después de probar la ruta nueva, vuelva a la anterior solo mediante la interfaz compatible e inspeccione el mismo conjunto de prueba. Confirme que la ruta antigua puede leer el estado resultante. Si la documentación de la candidata advierte de estructuras de datos irreversibles o en evolución, restablezca el entorno desechable en vez de suponer reversibilidad.
No elimine filas de la base de datos ni cambie manualmente el almacenamiento de indicadores para forzar un interruptor que la aplicación ya no exponga. Eso puede generar un estado híbrido no compatible y hacer engañosos los fallos posteriores.
Cuando un módulo se adapta a ambas rutas, pruebe que no aplique dos veces el mismo efecto de negocio. Una capa de compatibilidad que registra simultáneamente integraciones antiguas y nuevas puede necesitar una lógica de selección cuidadosa. El indicador por sí solo no demuestra que el módulo haya seleccionado correctamente una ruta.
Planificar la retirada de indicadores
Una estrategia de soporte basada en «decir a los clientes que desactiven la página nueva» puede ser una solución temporal, pero no es un plan de implementación duradero. Si la ruta antigua desaparece más adelante, la solución desaparece con ella.
Lleve un seguimiento de las personalizaciones que siguen dependiendo de una ruta antigua y de las pruebas necesarias para eliminar esa dependencia. Incluya el módulo o la agencia responsable y la operación de negocio pertinente.
Cuando se elimine un indicador en una versión posterior, actualice los nombres de los tests y la documentación. Un test que afirma probar una ruta antigua deshabilitada cuando el interruptor ya no existe genera una falsa confianza. Prefiera nombres de casos centrados en el comportamiento y registre la ruta de implementación como metadato del entorno.
Para los equipos de soporte, conserve el inventario de indicadores con cada incidente. Pedirlo pronto puede explicar por qué un problema se reproduce en una tienda y no en otra sin culpar a cachés aleatorias ni reinstalar módulos.
Gestionar un experimento de indicadores interrumpido
Suponga que un tester habilita una página migrada, edita datos de prueba y se ve interrumpido antes de registrar el resultado. Otro tester no debe deducir el estado activo del informe incompleto. Inspeccione el interruptor, vuelva a abrir los datos y compárelos con la base guardada antes de continuar.
Use un registro del experimento con tres etapas explícitas: preparado, ejecutado y revisado. Preparado significa que el estado inicial está documentado. Ejecutado significa que se capturaron las acciones y observaciones. Revisado significa que se interpretó el resultado y se conoce el estado final del entorno.
Esta es una práctica ligera de coordinación, no una nueva funcionalidad de PrestaShop. Resulta especialmente útil cuando varias personas comparten una instalación de pruebas y los interruptores afectan a más de una sesión de test.
Evite realizar comparaciones de rutas concurrentes sobre los mismos datos de prueba compartidos. Una persona que cambie el indicador o la configuración superior puede invalidar el resultado de otra. Use instancias desechables separadas para experimentos independientes cuando sea viable, o reserve el entorno para la ventana de pruebas pertinente.
Al terminar un experimento, indique si el entorno se restauró, se conservó para reproducir un error o se retiró. Conservar un estado con fallo puede ser una prueba útil, pero debe etiquetarse para que el siguiente tester no lo confunda con la base habitual.
Estos registros convierten un cambio de indicador en un experimento repetible. También permiten distinguir una investigación interrumpida de un defecto de la candidata cuando una sesión posterior encuentra una página inesperada.
Un interruptor debe producir conocimiento
El objetivo de evaluar un indicador de una candidata es saber si una ruta concreta admite una operación concreta. Termine cada experimento documentando el estado activo, el resultado y los cambios de datos que se hayan producido.
Si una ruta falla, conserve un caso mínimo reproducible. Si pasa, indique el alcance probado en vez de afirmar que está universalmente lista. Si nunca se probó, déjela explícitamente sin probar.
Los indicadores de funcionalidades posibilitan una migración gradual, pero también hacen menos descriptivos los números de versión por sí solos. Un inventario disciplinado y una comparación de ambas rutas convierten esos estados adicionales en pruebas útiles en vez de incertidumbre oculta.
Para conocer el contexto de la plataforma subyacente, consulte nuestra guía de desarrollo de módulos PrestaShop 9 y aplique las comprobaciones específicas de versión anteriores a la instalación que esté evaluando.