Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. Creative Coding

La teoría de los tests unitarios, parte 1

by
Difficulty:IntermediateLength:MediumLanguages:

Spanish (Español) translation by Eva Collados Pascual (you can also view the original English article)

Hemos estado viendo los tests unitarios para el desarrollo de WordPress. Mediante el uso de ejemplos prácticos, hemos revisado cómo son los tests unitarios tanto para plugins como para temas; sin embargo, realmente no hemos hablado de la teoría tras de ellos.

Es decir, no hemos visto qué es desde un alto nivel, por qué es beneficioso, ni cómo podemos incorporarlo en nuestro flujo de trabajo. En la siguiente serie de artículos, vamos a definir los test unitarios, cubriremos sus principales beneficios, por qué debemos molestarnos en realizarlos y algunos de los recursos que tenemos a nuestra disposición para usarlos en nuestro trabajo.

Aunque en este tutorial en concreto no hay código con el que trabajar, debería proporcionarte una base sólida sobre la que se basa la aplicación práctica de los anteriores artículos.


Sobre los tests unitarios de temas y plugins

Antes de sumergirnos en el artículo, creo que es importante considerar las razones por las que uno debe tomarse la molestia de comprobar los temas y los plugins.

Hasta hace poco, WordPress ha sido visto principalmente como una plataforma de blogs y como un sistema de gestión de contenido. Es perfecto para crear ambos, pero como los desarrolladores están descubriendo su rica API, se está volviendo más popular para construir ciertos tipos de aplicaciones utilizando WordPress como la plataforma subyacente.

Además, los temas son algo más que apariencias de interfaz o "skins" para un sitio web: son más que una hoja de estilos y algunos archivos de plantilla para mostrar datos. De hecho, ahora, tal vez más que nunca, equipos enteros están dedicando tiempo (e incluso se ganan la vida) produciendo temas para WordPress. Así que no dejes que la palabra "tema" te desvíe, los temas son como aplicaciones para WordPress. Añaden funcionalidad, preprocesan y post-procesan datos, y a menudo introducen una funcionalidad significativa en WordPress, mucho más allá que simplemente dar a tu sitio web un lavado de cara.

Por último, los plugins se asemejan casi más a las aplicaciones en su naturaleza que los temas. Considéralo de esta manera: los plugins extienden el núcleo de WordPress y a menudo funcionan independientemente de los temas. Añaden nuevas características al núcleo de WordPress de las que todos los temas puedan beneficiarse.

Digo todo esto para proporcionar una cierta perspectiva de por qué los tests unitarios, como estamos a punto de descubrir, pueden dar sus frutos muchas veces, dado que se utilizan en el contexto de temas y plugins más complejos.


¿Qué son los tests unitarios?

Unit TestsUnit TestsUnit Tests

Hicimos referencia a ello brevemente en el primer artículo de esta serie. No quiero proporcionar un recordatorio completo de lo que ya se ha escrito, así que resumiré los puntos aquí:

  • Es la práctica de asegurarse de que las unidades funcionales de código funcionan según lo esperado
  • Nos da la capacidad de encontrar fallos en nuestro código antes de lanzarlo públicamente
  • El código se vuelve más resistente con respecto a los cambios porque se está probando continuamente

Pero eso es rascar sólo la superficie.

Definir las unidades

Para entender realmente las unidades de tu tema o plugin, tienes que pensar en lo que compone un tema. Típicamente, es una combinación de lo siguiente:

  • Hojas de estilo que le proporcionan al tema su presentación
  • JavaScript (normalmente basado en jQuery) que administra el comportamiento del lado cliente
  • PHP que maneja el procesamiento del lado del servidor

Aunque existen frameworks de tests unitarios específicos para JavaScript, nosotros nos vamos a centrar más en el aspecto PHP del desarrollo de WordPress. Después de todo, si no fuera por la funcionalidad del lado del servidor, habría muy poca funcionalidad singular introducida en WordPress.

Dicho esto, hay varias maneras de definir una unidad, pero apuesto a que la mayoría de las personas la definen 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 constan de varios bloques, quizás bucles, quizás condicionales o quizás llamadas a otras funciones.

Sea cual sea el caso, a menudo existen unidades más pequeñas de funcionalidad contenidas en los métodos.

Entonces, ¿es realmente preciso decir que los tests unitarios implican la comprobación de cada función que compone un tema? La verdad es que no. Dado que un único bloque de código (o, en algunos casos, una sola instrucción) es responsable de lograr una tarea específica, estas formarían verdaderas unidades de código.

Y si se supone que debemos escribir tests unitarios, ¿cómo escribimos tests para las unidades que existen dentro de nuestras funciones?

Más tests, más métodos

Recuerda que al principio de la serie, dije lo siguiente:

  • Escribe tus tests primero y luego ejecútalos (por supuesto, fallarán)
  • Escribir código para intentar que los tests pasen
  • Ejecuta los tests. Si pasan, genial; de lo contrario, continúa trabajando en la función

Aquí es donde se produce uno de los mayores cambios en la escritura de código comprobable por unidad: 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 eso algo malo?

Al hacer esto, cada función tiene realmente un único propósito. Y suponiendo que la función hace una sola cosa, hay muchas maneras de nombrar la función que, en última instancia, podría dar lugar a un código mucho más legible.

Por supuesto, hay un equilibrio, dado que podrías estar introduciendo algunas líneas de código más al escribir estas funciones adicionales, pero cuando estás trabajando con un equipo formado por más personas en un producto que será utilizado por miles de clientes, tienes que preguntarte si el código adicional es compensado por los beneficios que proporcionan para realizar adecuadamente los tests de tu trabajo. Bien hecho, tu equipo debería ser capaz de 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 tests unitarios.

Unidades y Suites

Unit TestsUnit TestsUnit Tests

Una cosa clave a reconocer acerca de los tests unitarios es que no dependen unos de otros. Un solo tests unitario debe comprobar una sola cosa. Además, esto significa que un test unitario realmente sólo debe incluir una única aserción (aunque hay excepciones que se muestran aquí).

Recuerda: El propósito de un test unitario es evaluar la calidad de una sola unidad de código. Algunas unidades aceptarán argumentos, otras unidades no, algunas unidades devolverán valores, otras no. Cualquiera que sea el caso, tu test unitario debe evaluar todos los casos. Una sola unidad de código rara vez tendrá un único test.

En su lugar, diría que una buena regla general es que el número de tests asociados a una unidad de código se escala exponencialmente en función del número de inputs que acepte.

Por ejemplo:

  • Si tu unidad no acepta argumentos, es probable que haya un test
  • Si su unidad acepta un argumento, es probable que haya dos tests: una para el argumento esperado y otra para el que no lo es
  • Si tu unidad acepta dos argumentos, es probable que haya cuatro tests: una para cada combinación de argumentos: esperado, esperado; esperado, inesperado; inesperado, esperado; e inesperado, inesperado

¿Tiene sentido? La clave aquí es que vas a tener significativamente más tests que unidades; no hay una proporción de 1:1.

Por último, al realizar tests unitarios, a menudo verás la palabra "test suite" o "suite" utilizada al discutir las pruebas. Esto puede variar en función del contexto en el que se estén realizando los tests; sin embargo, cuando se trabaja con WordPress, esto generalmente se refiere a una colección de tests unitarios.

Supongamos que tienes un archivo que es responsable de comprobar toda la funcionalidad en torno a la escritura y publicación de una entrada: este archivo sería el conjunto de tests para las entradas. Bastante fácil, ¿verdad? Es importante entender esta terminología si te encuentra con esto en la lectura posterior, ya que podría diferir ligeramente si estás trabajando en, por ejemplo, Rails o .NET.

Agnóstico en relación a la plataforma

Por último, los tests unitarios no son una nueva metodología y no se limitan estrictamente a PHP. De hecho, los tests unitarios (o el desarrollo impulsado por tests en su conjunto) han existido durante más de una década.

Puedes encontrar frameworks de tests unitarios para Java, .NET, Rails, PHPUnit (obviamente), etc.

Pero su adopción ha sido mixta, algunas personas viven y mueren por ellos, otros los odian, y luego estamos los que esperamos comenzar a realizarlos, pero tenemos que equilibrar la aplicación práctica de llevarlo a un proyecto existente y entender la cantidad de refactorización que esto puede requerir.


A continuación

En cuanto a la teoría, estamos empezando.

En el siguiente artículo, echaremos un vistazo a los beneficios clave de los tests unitarios y cómo pueden dar sus frutos en nuestro desarrollo basado en WordPress. También examinaremos las ventajas que estos aportan a la arquitectura, el diseño y la documentación.

Por supuesto, los tests unitarios no están exentos de sus desventajas, así que también las veremos.

Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.