Introducción a las pruebas unitarias en WordPress – elementos básicos

No hay nada mejor que terminar tu día con una conciencia limpia, sabiendo que has hecho bien tu trabajo. Desafortunadamente, esta sensación reconfortante es bastante inusual entre los desarrolladores web, hay tantas cosas que pueden salir mal (navegadores, servidores, bibliotecas …) que es complicado relajarse por completo, ¿verdad?

“¡Mi código funciona! ¡Odio! ? ¿Ahora es un buen momento para trabajar en …? ” (Fuente) Bueno, ¡hoy es tu día de suerte! He preparado una serie de publicaciones en las que le enseñaré todo lo que necesita saber para asegurarme de que (a) su código funcione y (b) continuará funcionando “pase lo que pase”. Como probablemente adivinó el título, utilizaremos pruebas automáticas. Pero debido a que hay muchas cosas de las que podemos hablar, discutiremos las pruebas unitarias solo en WordPress, tanto en el servidor (PHP) como en el cliente (JavaScript). Si desea cubrir otros temas o tipos de pruebas, hágamelo saber y apretarlos?
En esta primera publicación comenzaremos con solo unas pocas definiciones sobre las pruebas y su utilidad. Mi objetivo es darle una idea clara de cómo las pruebas pueden ayudarlo en el trabajo cotidiano, así que (con suerte) estar ansioso por usarlo. La importancia de las pruebas (automatizadas). Si le importa su reputación, debe preocuparse por la calidad de su trabajo: no hay nada menos profesional que la carga de una nueva versión del complemento o la base en el repos. Funciona … y sé de lo que estoy hablando, porque me pasó a mí. Afortunadamente, aprendí de mis errores e implementé varias medidas de seguridad. Es imposible garantizar un lanzamiento sin error, pero puede minimizar las posibilidades utilizando pruebas automáticas. El ciclo de desarrollo habitual de cualquier nueva versión de su complemento o tema se ve así:
Tiene ciertos requisitos o características nuevas que desea incluir en su complemento.
Escriba el código que implementa esas características.
Pruébalo.
Si falla, intente solucionarlo y volver al paso 3.
Una vez que funcione, repita los pasos 2, 3 y 4, hasta que se cumplan todos los requisitos.
Te aseguras de que todo sigue funcionando de acuerdo con las expectativas.
Actualice la nueva versión en wordpress.org.
Y … ¡BAM! Alguien encuentra un nuevo error.
Bastante complicado, ¿verdad? Hay muchas pruebas “manuales” solo para asegurarse de que las cosas funcionen correctamente. El problema de las pruebas “manuales” es que prueba las cosas una vez: después de haber verificado que funciona, simplemente se olvida de ellas. Y probablemente funcionaría, si el código fuera estático … pero el código cambia, evoluciona. Por lo tanto, hay una gran oportunidad de romper las cosas a medida que pasa el tiempo: cuando cambia su complemento o tema para incluir una nueva funcionalidad, aparecen algunos efectos secundarios imprevistos y cosas que funcionaron antes. Idealmente, necesitamos una red segura para garantizar que si Algo antes de que se funcionara y no esté roto, lo sabremos antes de lanzar una nueva versión. ¡Y eso es precisamente lo que son las pruebas!
Bueno, no solo las redes seguras pueden hacer un truco; ¿Los paracaídas funcionan bastante bien? (fuente) Dependiendo del “tamaño” del elemento probado, hablaremos sobre pruebas unitarias (módulos pequeños), pruebas de integración (cómo funcionan los componentes en su totalidad) y otros, como las pruebas de aceptación (donde probamos todo el sistema, como si fuera un usuario habitual). Independientemente del tipo específico de prueba que creamos, todos siguen el mismo modelo:
Configurar. En primer lugar, debe preparar el entorno para que la condición inicial sea siempre la misma. Por ejemplo, es posible que desee cargar un volcado de base de datos en el que hay una sola publicación específica con una identificación y título en particular.

Acto. Luego aplique algunas acciones que cambiarán esta condición inicial (agregue una publicación, cambie el título, borre un comentario).
Échale un vistazo. Finalmente, ha verificado si la condición/resultado final es exactamente lo que espera. Por lo tanto, por ejemplo, si su blog solo tenía una publicación en (1) y la ha eliminado en (2), espere que su blog no tenga publicaciones en (3). Para garantizar que su código funciona. Verifican si una pieza atómica de su función de software, generalmente funciona de acuerdo con la intención. Al igual que cualquier otra prueba, una prueba unitaria simplemente verificará que, dada una determinada entrada, obtenemos el resultado esperado.
Hasta ahora, todo es teoría abstracta … así que veamos un ejemplo, ¿verdad? Imagine que alguien le pide que cree una función que, en vista de una suma de dinero, devuelva el IVA apropiado. En España, se establece en el 21%, por lo que el IVA de algo que cuesta 10 EUR es de 2.10 euros. Esta característica se implementa muy fácilmente, ¿no? Función neli_get_vat ($ cantity) {
devolver $ cantidad * 0.21;
} // termina no -oli_get_vat ()
Ahora, si llamamos a la función de la siguiente manera: neli_get_vat (10), obtenemos el resultado esperado: 2.1. Ahora hagamos las cosas un poco picantes. Supongamos que $ cantidad es un valor de usuario. Debido a que somos buenos programadores, queremos aceptar varios formatos (en lugar de obligar al usuario a ingresar valores con un solo formato específico):
Precio simple: 1000
Precio con miles de separadores: 1,000 (coma) o 1 000 (espacio)
Precio de la moneda: 15 €, 15 €, 15 euros, 1 euro o 3 euros
Precio con y sin centavos: 15.00, 15.50 o 15.
Combinando formatos anteriores: 1,500.00 EUR o 1200.50.
Es bueno hablar de dinero, ¿no? Bueno, no es tan bueno tenerlo, pero aún así … si queremos aceptar todos esos formatos, la función ya no puede tomar la entrada, supongamos que es un número y lo multiplicamos por 0.21, porque hay más escenarios en ¿Qué cantidad $ no es un número, sino una cadena con caracteres “extraños”? Independientemente de la implementación concreta que podamos usar, sabemos que las siguientes afirmaciones deben ser ciertas: si el precio dado es 1000, el IVA es 210.
Si el precio dado es de 15 €, el IVA es 3.15.
Si el precio dado es de 1,200.50 euros, el IVA es 252.11.

Y eso es exactamente lo que una prueba unitaria verificará. Una prueba unitaria verifica si, dada una determinada entrada, los resultados obtenidos son iguales al resultado esperado. En inglés simple, una prueba unitaria se vería así:

Hey neli_get_vat, si te doy el número 1000, ¿qué obtengo? Espero a los 210.
Oye neli_get_vat, si le doy una cadena de 15 €, ¿qué obtengo? Espero a las 3.15.
Oye neli_get_vat, si le doy la cadena 1,200.50 eur, ¿qué obtengo? Espero en 252.11.
Si alguno de los controles anteriores (que, por cierto, se denomina afirmaciones) es falsa, la prueba fallará y sabremos que algo no está bien con nuestra función. Además, si cambiamos la función en el futuro, nuestro conjunto de pruebas detectará si hemos roto algo inesperadamente; si lo hicimos, la prueba que pasó fallará y sabremos que algo no está bien.
Pruebas de integración Como acabamos de ver, utilizamos pruebas unitarias cuando queremos probar porciones atómicas de nuestro código (es decir, funciones; a veces incluso clases). Pero un complemento es mucho más que funciones individuales: cuando todas las diferentes partes de nuestro complemento se encuentran, tienen un propósito mayor y resuelven un problema mayor. Si queremos asegurarnos de que todos los componentes diferentes funcionen correctamente, entonces necesitamos un nuevo tipo de pruebas: pruebas de integración. Podría intentar describir las pruebas de integración, pero el próximo tweet lo resume perfecto: prueba unitaria vs prueba de integración pic.twitter.com/tquuuwibcmr – Moshe Vardi (@vardi) 25 de septiembre de 2016 divertido, ¿verdad? Este video nos enseña la importancia que cada prueba tiene en la calidad final de nuestro producto. En primer lugar, muestra que una prueba unitaria pasaría tanto para el pestillo como para la puerta: por un lado, podemos deslizar correctamente el pestillo para que esté bloqueado o desbloqueado y, por otro lado, podemos abrir y cerrar la puerta. usando el manillar. ¡Eso es genial! La prueba de integración muestra que algo está mal con el sistema. Una prueba de integración verificaría, por ejemplo, que no se puede abrir una puerta cerrada. ¡Pero este no es el caso aquí! Puede que haya cerrado el pestillo, pero la puerta aún puede estar abierta. ¿Así que lo que ocurre?
A veces, podemos crear componentes que satisfagan sus especificaciones y, por lo tanto, pasen sus pruebas, pero no están destinadas a trabajar juntos como parte de un todo más grande. En este caso, el tipo de puerta que usamos no es compatible con el pestillo, ni con el pestillo con la puerta, lo que significa que debemos cambiar una u otra para cumplir con las especificaciones de una “puerta cerrada”. Las pruebas de aceptación El último tipo de pruebas de las que me gustaría hablar hoy son las pruebas de aceptación, que discutí en mi presentación en WordCamp Europe 2015 (en Sevilla). Las pruebas de aceptación son bastante similares a las pruebas de integración, porque ambas prueban el sistema en su conjunto. Las pruebas de integración tratan el sistema como una caja blanca. Verifican que las diferentes partes del complemento /tema sean plenamente conscientes de lo que hay debajo del capó. Es decir, una prueba de integración sabe y puede verificar lo que está sucediendo en la base de datos, qué resultados se calculan, etc. Es equivalente al tipo de prueba que haría un “desarrollador”. Las pruebas de aceptación, por otro lado, validan el comportamiento del sistema suponiendo que sea una caja negra. En una caja negra, no sabe qué hace su código: solo puede ver el resultado final como lo haría un usuario normal. Usando la herramienta apropiada (utilicé Codeception en el pasado y la adoro), puede escribir pruebas que simulen la interacción de un usuario con su navegador. Por ejemplo, si queremos verificar el proceso de “autenticación” de una instalación de WordPress, escribiríamos la siguiente prueba: vaya a http://local.wordpress.dev/wp-login.php
Use el nombre de usuario “David” y la contraseña “Contraseña”.
Haga clic en Iniciar sesión.
Espero leer el texto “bueno, David” desde la esquina superior derecha de la página. ¿Ves la diferencia? No sabemos cómo se autentica el usuario, no sabemos nada sobre lo que hay debajo del capó … simplemente describimos una interacción entre un usuario y nuestro sistema. ¡Loca! Desarrollo basado en la prueba (TDD) Antes de completar esta publicación, quería hablar con usted sobre un “nuevo” enfoque para escribir software – Desarrollo impulsado por pruebas (TDD). Si observa más de cerca lo que hemos descrito hasta ahora, verá que el flujo de trabajo es el siguiente:
Usted escribe un código,
Creas pruebas que lo verifican,
Ejecute las pruebas y asegúrese de que todo funcione como se esperaba.
Bueno, TDD se trata de hacer cosas lo contrario:
Primero escriba la prueba para una nueva funcionalidad,
Verifique que la prueba falle (y fallará, porque no ha escrito ningún código para esa nueva funcionalidad),
Escriba un nuevo código para resolver el problema en cuestión,
Realice la prueba y asegúrese de que, después de que termine el nuevo código, pase.