Mejores prácticas para la prueba de regresión Sitios web de WordPress?

Hola a todos,

Me gustaría saber qué otros que están ofreciendo soluciones complejas que no son de blog a los clientes con WordPress como plataforma, ¿qué utilizan 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), al volver 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 haya introducido nuevos errores.

Más de 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 se repara el software, la aparición de nuevas y / o resurgencias de fallas antiguas es bastante común. A veces, la reemergencia ocurre porque una solución se pierde a través de prácticas de control de revisión deficientes (o un simple error humano en el control de revisión). A menudo, una solución para un problema será "frágil", ya que soluciona el problema en el caso estrecho donde se observó por primera vez, pero no en casos más generales que pueden surgir durante la vida útil del software. Con frecuencia, una solución para un problema en un área provoca inadvertidamente un error de software en otra área. Finalmente, a menudo ocurre que cuando se rediseña alguna característica, algunos de los mismos errores que se cometieron en la implementación original de la característica se cometieron en el rediseño.

Con la naturaleza global de las acciones y los filtros, descubro que la complejidad comienza a aumentar a medida que agrego más funcionalidades solicitadas por el cliente y se hace difícil lograr que un complemento complejo sea estable, especialmente si usa muchas llamadas WP_Queryy actualiza mucho la base de datos .

La solución en mi mente sería establecer pruebas de regresión con una serie de "casos de prueba" para comprender 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 un wiki de la comunidad con la esperanza de que podamos reunir las mejores prácticas aquí, pero estoy realmente ansioso por escuchar procesos si otros profesionales de WordPress están utilizando.

PHPUnit me vendría a la mente, si el paquete 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, puedes probar tus complementos todo lo que quieras desde su punto de vista funcional con pruebas unitarias y similares. El problema es que estas pruebas no garantizarán que atraparán sutiles posibilidades 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 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 WP_Errorobjeto en lugar del valor esperado anteriormente falsecomo entrada incorrecta.

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

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

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

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

• Un complemento (¿?

Podría ampliar la lista una y otra vez, pero esos serían los elementos clave que rompieron mis propios complementos. Los dos artículos son discutibles con pruebas unitarias. Los dos siguientes también, si eres lo suficientemente paciente, pero 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 con errores de switch_to_blog (). Y los dos últimos son irremediablemente incontestables.

Ah, y ... ni siquiera me hagas comenzar con la avalancha de archivos adjuntos, borradores automáticos, revisiones, elementos de menú y lo que no termina almacenado en la tabla de publicaciones.

Buena suerte... :-)

Debe considerar seriamente el selenio .

Le permite registrar acciones (por ejemplo, ingresar datos en un formulario, hacer clic en un enlace) y luego puede realizar afirmaciones. También se integra con PHPUnit. Recomiendo ver la demostración de dos minutos.

El selenio es probablemente utilizable, pero creo que en los tiempos modernos encontrará que Codeception es mejor y más fácil de usar. Para la prueba de regresión visual más simple, incluso tiene una extensión que tomará capturas de pantalla y las comparará automáticamente.

Por supuesto, las pruebas de Codeception WebDriver pueden ir más allá y realizar pruebas de regresión funcional . Puede completar y enviar formularios, hacer clic en botones y enlaces en el sitio, ejecutar cualquier JS, etc. Puede usar un navegador de la vida real como Firefox o Chrome en sus pruebas, o puede realizar pruebas sin cabeza con PhantomJS . Eso significa que incluso puede ejecutar las pruebas de WebDriver para su complemento como parte de su proceso de compilación en Travis CI si lo desea.

Incluso hay varias bibliotecas específicas de WordPress para ayudarlo a comenzar:

• WP Browser
• Codecepción de WP