Share
En el último artículo, comenzamos a hablar sobre la teoría de las pruebas unitarias en WordPress. Específicamente, revisamos nuestro trabajo sobre temas y complementos de pruebas unitarias y luego comenzamos a discutir las unidades de código, cómo esto afecta nuestras pruebas, y revisamos las pruebas unitarias en el mundo más amplio del desarrollo de software..
Continuaremos discutiendo la teoría de las pruebas unitarias en WordPress, pero lo haremos a través de la perspectiva de cómo puede ayudar a identificar problemas, impulsar la arquitectura, documentar el proyecto y más..
Recordemos anteriormente en esta serie, que la forma tradicional de hacer pruebas unitarias es esta:
Sí, el primer paso es un poco dogmático. ¿Por qué perder minutos ejecutando algo que sabes que va a fallar, verdad? Aun así, entiendes la idea. Pero cuando empieces a aplicar esta técnica en particular al desarrollo, verás que desarrollarás un cierto ritmo para escribir tu código y eso es parte de todo el objetivo..
Pero eso es solo la mitad: las pruebas unitarias pueden ayudarlo a detectar problemas al principio del desarrollo.
Para comprender, probablemente es mejor volver a la idea..
Digamos que está trabajando en una función para un proyecto basado en WordPress en el que va a permitir que los usuarios creen una cuenta de usuario sin iniciar sesión en el panel de WordPress. Esto supone que tiene una configuración de plantilla de página para gestionar el registro, la validación necesaria y el código para generar contraseñas y correos electrónicos.
Cargas la página en tu navegador, intentas crear algunos usuarios, algunos con la misma dirección de correo electrónico, algunos con contraseñas incorrectas, otros con caracteres ilegales, etc. Obtienes el punto: hay un número n de formas para la validación. Pasar y fallar. ¡Esto es duro! Esto significa que cada vez que se cambia la función de registro de usuario, debe realizar el mismo número n de registros para asegurarse de que no se rompa nada.
O puede escribir un conjunto de pruebas para cuidarlo y ejecutarlas todas cada vez que cambie el código..
Entonces, sí, escribir pruebas unitarias puede llevar mucho tiempo al principio, pero mire la cantidad de tiempo ahorrado cada vez que modifica una unidad de código. Vale la pena y esto puede ayudar a identificar los problemas desde el principio, es decir, antes de que se publique en producción, que podría haberse perdido porque alguien se olvidó de simular una permutación de la prueba..
Cuando se trata de escribir pruebas unitarias, no solo está mejorando la calidad de su código al garantizar que realmente funciona, sino que también proporciona documentación orientada al desarrollador..
Si realiza una prueba unitaria de la funcionalidad que está incorporando en su producto, proporcionará documentación sobre cómo deben funcionar las funciones, cuándo deben fallar y cuándo deben aprobarse..
Hay algunas suposiciones que vienen con esto: Específicamente, que está nombrando y agrupando lógicamente sus funciones y sus pruebas asociadas y que está probando cada función adecuadamente.
A través de PHPUnit, las pruebas unitarias de WordPress facilitan la realización de aserciones que son fáciles de leer. Simplemente declara assertTrue, assertFalse o cualquier otra aseveración disponible en las funciones que componen su proyecto..
Siguiendo con nuestro ejemplo anterior, esto significa que puede escribir una función para asegurarse de que la función de registro del usuario falla al intentar registrarse con una dirección de correo electrónico vacía:
Accentsconagua
$ this-> assertFalse (registerNewUser (")); Un ejemplo simple, tal vez, pero el punto permanece: su código se autodocumenta y solo requiere que escriba pruebas de unidad claras.
Quizás una de las ventajas más subestimadas de las pruebas unitarias es que puede ayudar a impulsar la arquitectura de su proyecto. Por lo general, el desarrollo de temas o complementos puede comenzar de dos maneras:
Estos no son intrínsecamente malos, pero creo que son débiles (¡y seré el primero en admitir que he hecho más de lo que me gustaría compartir!). Pero el paso "escribir código" asume mucho, no lo hace?
Para cualquiera que haya estado escribiendo código durante un amplio período de tiempo, todos están tan familiarizados que terminan llegando al punto en el que se dan cuenta: "Oh ... no pensé en eso".
Si tiene suerte, esto generalmente significa que puede escribir un método auxiliar u otro condicional para manejar el caso que descuidó, pero en el peor de los casos, significa que puede tener que volver a trabajar toda su clase o todo su conjunto de funciones para acomodar este problema.
Las pruebas unitarias, aunque no son perfectas, pueden ayudar a mitigar esto.
Considere el hecho de que, desde el principio, está enumerando todas las funciones que desea que su tema o complemento ofrezca. Aún no ha escrito ningún código, pero quizás tenga algún tipo de esquema de la interfaz de usuario y / o un conjunto de diagramas de clase.
A continuación, comienza a escribir las pruebas que va a estar escribiendo para probar su proyecto. Recuerde que parte de las pruebas de unidad está dividiendo el código en la unidad más atómica posible, por lo que tiene la tarea de escribir pruebas de unidad para cada uno de estos, Ejem, unidades.
Debido a la naturaleza de las pruebas unitarias, intrínsecamente estás pensando en tu código de manera diferente: en lugar de "escribir código", estás pensando en "escribir pruebas", y porque tienes que pensar a un nivel más atómico, puedes No ayude, pero considere los casos marginales que a menudo se agrupan en "escribir código".
Como desarrolladores, estamos demasiado cómodos con el uso de convenciones que refuerzan continuamente que escribimos código. Con eso, quiero decir que tendemos a proporcionar nombres abreviados de variables, nombres de funciones crípticas y nombres de clases que pueden no significar nada para nadie fuera de usted o del equipo que está trabajando en su proyecto..
La prueba de unidad no es necesariamente la clave para escribir un código que sea más fácil de leer, pero puede ir un poco más lejos para ayudar a proporcionar nombres de funciones más limpios.
Recuerde el primer libro de programación que leyó, la primera clase de informática que tomó, o la primera pieza de código fuente abierto que vio, los nombres de los métodos suelen ser verbos. ¿Por qué no deberían ser? Los métodos son formas de encapsular código que hace cosas. Pero a medida que trabajamos en proyectos por más y más tiempo, nos volvemos cada vez más perezosos y nuestro código va desde "register_user_and_email_password ()" a "nueva cuenta()".
Obviamente, el primero es más limpio que el segundo, pero si nos esforzamos por realizar pruebas de unidad de calidad y queremos asegurarnos de que nuestras pruebas de unidad sean fáciles de leer y para que sean fáciles de leer, nuestros nombres de funciones deben ser fácil de leer.
¿No es esto más fácil de leer?
$ this-> assertFalse (register_user_and_email_password (")); En lugar de esto?
$ this-> assertFalse (new_account (")); De nuevo, quizás este sea un ejemplo simple, pero el principio sigue siendo: Escribir buenas pruebas unitarias para ayudar a documentar el código que controla el idioma de sus funciones..
Hemos hablado de los conceptos básicos de las pruebas unitarias, así como de los beneficios clave, pero aún tenemos que discutir las desventajas que vienen con las pruebas unitarias y ni siquiera hemos echado un vistazo a cómo incorporarlo en nuestro flujo de trabajo..
Así que en el próximo artículo, intentaremos hacer precisamente eso..
