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

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

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 garantizan que captarán las posibilidades sutiles introducidas por las actualizaciones de WP, y mucho menos que continuarán funcionando una vez que estén conectadas a una instalación de WP personalizada.

Entre las cosas coloridas que he visto pasar:

• Un cambio sutil en la API de WP afecta la funcionalidad de su complemento, por ejemplo. el gancho en el que se usa 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 la misma identificación para ambos).

• Un cambio sutil en la API de WP hace que recibas un objeto WP_Error en lugar del valor previamente esperado de false como 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 se habilitó memcached u otra tienda persistente.

• Su complemento funcionó bien hasta que se llamó el despreciable switch_to_blog ().

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

• Un complemento (¿un?) intuye a sabiendas con sus datos de entrada o salida hasta el punto en que las cosas se ven dañadas aunque 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. Los dos artículos son discutibles con pruebas de unidad. Los próximos dos también, si eres lo suficientemente paciente, pero argumentarí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 imposibles de probar.

Ah, y ... ni siquiera me refiero a 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 ... :-)

Debería considerar seriamente Selenium .

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

El selenio probablemente se pueda usar, 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 Compararlos automáticamente por ti.

Por supuesto, las pruebas de Codeception WebDriver pueden ir más allá y realizar pruebas de regresión funcionales . Puede completar y enviar formularios, hacer clic en los 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 quieres.

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

• Navegador WP
• Codeception WP