customization – ¿Mejores prácticas para realizar pruebas de regresión en sitios web de WordPress?

Pregunta:

Hola a todos,

Me gustaría escuchar lo que otros que están ofreciendo soluciones complejas que no son blogs a clientes con WordPress como plataforma, ¿qué están usando para las pruebas de regresión automatizadas?

Para aquellos que no están familiarizados con el término "prueba de regresión", Wikipedia lo define como:

La prueba de regresión es cualquier tipo de prueba de software que busca descubrir errores de software después de que se hayan realizado cambios en el programa (por ejemplo, correcciones de errores o nuevas funciones), volviendo a probar el programa. La intención de las pruebas de regresión es asegurar que un cambio, como una corrección de errores, no introdujo errores nuevos.

Wikipedia dice lo siguiente, que es exactamente lo que estoy experimentando en un proyecto en este momento:

La experiencia ha demostrado que a medida que el software se repara, la aparición de fallas nuevas y / o la reaparición de viejas fallas es bastante común. A veces, el resurgimiento se produce porque una solución se pierde debido a prácticas deficientes de control de revisiones (o un simple error humano en el control de revisiones). A menudo, una solución para un problema será "frágil" en el sentido de que soluciona el problema en el caso limitado en el que se observó por primera vez, pero no en los casos más generales que pueden surgir durante la vida útil del software. Con frecuencia, la solución de un problema en un área provoca inadvertidamente un error de software en otra área. Por último, a menudo ocurre que cuando se rediseña alguna función, algunos de los mismos errores que se cometieron en la implementación original de la función se cometieron en el rediseño.

Con la naturaleza global de las acciones y los filtros, encuentro que la complejidad comienza a aumentar a medida que agrego más funcionalidades solicitadas por el cliente y se vuelve difícil obtener un complemento complejo estable, especialmente si usa muchas llamadas a WP_Query y actualiza la base de datos a lote.

En mi mente, la solución sería configurar las pruebas de regresión con una serie de "casos de prueba" para formar un "conjunto de pruebas". En concepto, no es tan difícil cuando está probando la salida HTML de las solicitudes HTTP GET. Pero se vuelve un poco más complicado cuando tienes que probar cosas cuando inicias sesión a través de la consola de administración y / o probar las interacciones de jQuery.

Estoy configurando esto como una wiki comunitaria con la esperanza de que podamos recopilar las mejores prácticas aquí, pero estoy realmente ansioso por escuchar los procesos si otros profesionales de WordPress están usando.

Respuesta:

PHPUnit me vendría a la mente, si el conjunto de pruebas de WP no estuviera tan roto, y si WP hubiera sido diseñado y escrito de una manera que realmente pudiera probarse correctamente. 😉

Más en serio, puede probar sus complementos todo lo que quiera desde su punto de vista funcional con pruebas unitarias y similares. El problema es que estas pruebas no garantizarán que detecten las oportunidades sutiles introducidas por las actualizaciones de WP, y mucho menos que continuarán funcionando una vez que se conecten a una instalación de WP personalizada.

Entre las cosas coloridas que he visto suceder:

  • Un cambio sutil en la API de WP afecta la funcionalidad de su complemento, por ejemplo, el gancho en el que está utilizado para obtener una identificación de término y ahora está obteniendo una identificación de taxonomía de término. (Es muy probable que sus términos de prueba tengan convenientemente la misma identificación para ambos).

  • Un cambio sutil en la API de WP da como resultado que reciba un objeto WP_Error lugar del valor esperado anteriormente de false como entrada incorrecta.

  • Su complemento se agrega desde la carpeta mu-plugins, lo que da como resultado un flujo de código sutilmente diferente.

  • Su complemento funcionó bien hasta que se habilitó Memcached o alguna otra tienda persistente.

  • Su complemento funcionó bien hasta que se llamó al despreciado switch_to_blog ().

  • Un complemento cambia el gancho en el que reside cuando se llama y, sin saberlo, lo interrumpe como efecto secundario.

  • Un complemento (¿no?) A sabiendas se mete con sus datos de entrada o salida hasta el punto en que las cosas parecen estar rotas aunque usted no tenga la culpa.

Podría expandir la lista una y otra vez, pero esos serían los elementos clave que rompieron mis propios complementos. Podría decirse que los dos elementos se pueden detectar con pruebas unitarias. Los dos siguientes también, si es lo suficientemente paciente, pero yo diría que WP no debería cambiar la forma en que funcionan las cosas cuando ocurren. Ninguna cantidad de pruebas funcionará alrededor de la implementación defectuosa de switch_to_blog (). Y los dos últimos son irremediablemente incontrolables.

Ah, y … ni siquiera me hagas empezar con la avalancha de archivos adjuntos, borradores automáticos, revisiones, elementos del menú y todo lo que acaban almacenados en la tabla de publicaciones.

Buena suerte… 🙂

Leave a Comment

Your email address will not be published.

Scroll to Top

istanbul avukat

-

web tasarım