Share
Hemos estado buscando pruebas de unidad para el desarrollo de WordPress. A través del uso de ejemplos prácticos, hemos revisado cómo se ven las pruebas unitarias tanto para los complementos como para los temas; Sin embargo, no hemos hablado realmente sobre la teoría detrás de las pruebas unitarias..
Es decir, no hemos analizado en alto nivel qué es, por qué es beneficioso y cómo podemos incorporarlo en nuestro flujo de trabajo. En la próxima serie de artículos, definiremos las pruebas unitarias, cubriremos sus beneficios clave, por qué debemos molestarnos en hacerlo y algunos de los recursos disponibles para que los utilicemos en nuestro trabajo..
Si bien no hay un código con el que trabajar para este tutorial en particular, debe proporcionar una base sólida en la que se base la aplicación práctica de los artículos anteriores..
Antes de profundizar en el artículo, creo que es importante considerar las razones por las que uno debería molestarse en probar temas y complementos..
Hasta hace poco, WordPress ha sido visto principalmente como una plataforma de blogs y como un sistema de gestión de contenido. Hace tanto de estos muy Bueno, pero a medida que los desarrolladores están descubriendo su rica API, se está volviendo más popular construir ciertos tipos de aplicaciones utilizando WordPress como la plataforma subyacente..
Además, los temas son más que máscaras para un sitio web, son más que una hoja de estilo y unos pocos archivos de plantilla para mostrar datos. De hecho, ahora, tal vez más que nunca, equipos enteros dedican tiempo (e incluso se ganan la vida) a producir temas para WordPress. Así que no deje que la palabra "tema" lo engañe: los temas son como aplicaciones para WordPress. Agregan funcionalidad, procesan previamente y post-procesan datos, ya menudo introducen una funcionalidad significativa en WordPress que va más allá de simplemente darle un cambio de cara a su sitio web.
Finalmente, los complementos son casi más parecidos a una aplicación en la naturaleza que a los temas. Considérelo de esta manera: los complementos extienden el núcleo de WordPress y, a menudo, funcionan independientemente de los temas. En su lugar, agregan nuevas características al núcleo de WordPress, de lo que todos los temas pueden beneficiarse..
Digo todo esto para dar una perspectiva de por qué las pruebas unitarias, como estamos a punto de descubrir, pueden dar resultados muchas veces, dado que se usan en el contexto de temas y complementos más complejos..
Nos referimos brevemente a esto en el primer artículo de la serie. No quiero proporcionar una repetición total de lo que ya se ha escrito, así que resumiré los puntos aquí:
Pero eso es solo arañar la superficie..
Para comprender realmente las unidades de su tema o plugin, debe pensar en qué compone un tema. Típicamente, es una combinación de:
Aunque existen marcos de prueba de unidad específicamente para JavaScript, nos centraremos más en el aspecto de PHP del desarrollo de WordPress. Después de todo, si no fuera por la funcionalidad del lado del servidor, habría muy poca funcionalidad única introducida en WordPress.
Dicho esto, hay varias formas de definir una unidad, pero apostaría a que la mayoría de las personas definen una unidad como una función. En su mayor parte, eso es correcto, pero no significa que nuestras funciones sean las unidades más óptimas para probar. Por ejemplo, las funciones a menudo consisten en múltiples bloques: tal vez bucles, tal vez condicionales, o quizás llamadas a otras funciones.
Cualquiera que sea el caso, a menudo hay unidades más pequeñas de funcionalidad contenidas dentro de los métodos.
Entonces, ¿es realmente exacto decir que las pruebas unitarias implican probar cada función que conforma un tema? Realmente no. Dado que un solo bloque de código, o, en algunos casos, una sola declaración, es responsable de lograr una tarea específica, estas constituiría verdaderas unidades de código.
Y si se supone que debemos escribir pruebas unitarias, ¿cómo escribimos pruebas para las unidades que existen dentro de nuestras funciones??
Recordemos que anteriormente en la serie, dije:
Aquí es donde ocurre uno de los mayores cambios en la escritura del código de unidad comprobable: estás dividiendo las unidades de funcionalidad en la pieza atómica más pequeña posible. Claro, esto a menudo resulta en un gran número de funciones muy pequeñas, pero es algo malo.?
Al hacer esto, cada función tiene verdaderamente un solo propósito. Y suponiendo que su función hace una sola cosa, hay tantas formas de nombrar la función que en última instancia puede resultar en un código mucho más legible.
Por supuesto, existe una compensación, ya que puede que esté introduciendo algunas líneas de código más mientras escribe estas funciones adicionales, pero cuando está trabajando en un producto con un equipo de otras personas que serán utilizados por miles de clientes, debe preguntarse si el código adicional vale la calidad que puede obtener al probar adecuadamente su trabajo. Bien hecho tu equipo debería podrá seguir más fácilmente la lógica del código y el producto tendrá un nivel de calidad que a menudo es difícil de lograr sin escribir pruebas unitarias.
Una cosa clave que se debe reconocer acerca de las pruebas unitarias es que no dependen entre sí. Una prueba de una sola unidad debe probar una y solo una cosa. Además, esto significa que una prueba de unidad debería incluir realmente una sola afirmación (pero hay excepciones que se demuestran aquí).
Recuerde: El propósito de una prueba de unidad es evaluar la calidad de una sola unidad de código. Algunas unidades aceptarán argumentos, algunas unidades no aceptarán, algunas unidades devolverán valores y otras no. Cualquiera que sea el caso, su prueba de unidad debe evaluar todos los casos. Una sola unidad de código rara vez tendrá una sola prueba.
En cambio, diría que una buena regla general es que el número de pruebas asociadas con una unidad de código se escala de forma exponencial en función del número de entradas que acepta.
Por ejemplo:
¿Tener sentido? La clave aquí es que vas a tener significativamente más pruebas que unidades; no hay una proporción de 1: 1.
Finalmente, al realizar pruebas unitarias, a menudo verá la palabra "conjunto de pruebas" o "conjunto" que se usa cuando se analizan las pruebas. Esto puede variar según el contexto en el que se está realizando la prueba; Sin embargo, cuando se trabaja con WordPress, esto generalmente se refiere a una colección de pruebas unitarias..
Entonces, digamos que usted tiene un archivo que es responsable de probar todas las funciones relacionadas con la escritura y publicación de una publicación; este archivo sería el conjunto de pruebas para las publicaciones. Bastante fácil, ¿verdad? Es importante comprender esta terminología en caso de que veas esto en otras lecturas, ya que puede diferir ligeramente si trabajas en, por ejemplo, Rails o .NET..
Finalmente, las pruebas unitarias no son una nueva metodología y no se limitan estrictamente a PHP. De hecho, las pruebas unitarias (o el desarrollo basado en pruebas en general) han existido durante más de una década..
Puede encontrar marcos de pruebas unitarias para Java, .NET, Rails, PHPUnit (obviamente), etc..
Pero su adopción ha sido mixta: algunas personas viven y mueren por ella, otras la odian, y luego estamos los que estamos buscando comenzar a hacerlo, pero tenemos que equilibrar la aplicación práctica de incorporarla a un proyecto existente y comprender el cantidad de refactorización esto puede requerir.
En lo que a teoría se refiere, apenas estamos empezando.
En el siguiente artículo, analizaremos específicamente los beneficios clave de las pruebas unitarias y cómo puede dar resultados en nuestro desarrollo basado en WordPress. También examinaremos las ventajas que las pruebas de unidad aportan a la arquitectura, el diseño y la documentación..
Por supuesto, las pruebas unitarias no están exentas de desventajas, por lo que también las analizaremos..
Accentsconagua