Escribir pruebas unitarias para complementos de WordPress

 

 

 

  • ¡Registro!
  • Accesibilidad para diseñadores, con Stéphanie Walter

  • Índice
    1. Lecturas adicionales sobre SmashingMag:
    2. Conceptos básicos de la unidad Q
    3. Una prueba unitaria real
    4. Integrando QUnit con WordPress
    5. La primera prueba unitaria
    6. Qué hacer la prueba unitaria
      1. Pruebas unitarias asincrónicas
      2. Eso no es una prueba unitaria
    7. Qué no hacer en la prueba unitaria
    8. Las pruebas unitarias me salvaron el trasero
    9. Los complementos populares son complementos estables

    Cuando mi complemento de WordPress tenía sólo tres usuarios, no importaba mucho si lo rompía. Cuando alcancé las 100.000 descargas, cada nueva actualización me hacía sudar las manos.

     

    Mi primer objetivo para el Calendario editorial de WordPress fue que hiciera algo útil. Era nuevo en JavaScript y PHP y realmente no sabía qué podía lograr. En unos días tuve una prueba de concepto. En algunos más tenía una versión funcional y les pedí a mis amigos que la instalaran. El calendario funcionó... más o menos.

    Lecturas adicionales sobre SmashingMag:

    • Cómo utilizan los desarrolladores de complementos comerciales el repositorio de WordPress
    • Infecciones comunes de malware de WordPress
    • Administre eventos como un profesional con WordPress
    • Complementos de administración gratuitos útiles para WordPress

    Dediqué tres veces más tiempo a corregir errores que a codificar. Una vez que el complemento funcionó, escribí pruebas unitarias para asegurarme de que siguiera funcionando.

    Las pruebas unitarias para mi calendario usan QUnit , pero en realidad solo usan tres funciones test: expecty ok. Este artículo le muestra cómo integrar pruebas unitarias en su complemento de WordPress, dónde escribir pruebas unitarias y cómo pueden ayudarlo.

    Conceptos básicos de la unidad Q

    Las pruebas unitarias siguen un patrón básico: haz algo y luego verifica los resultados. (“¿Esta variable está 4cuando debería estar 5?” “¿Esta línea de mi tabla aparece donde se supone que debe aparecer?”)

    function myTest() { test('My test run', function() { expect(2); ok(5 === 5, 'This test will always pass'); ok(5 === 6, 'This test will always fail'); });}

    Esta estructura te obliga a pensar en tu código en unidades simples que devuelven trueo false. La testfunción inicia una ejecución de prueba con dos argumentos: el título de esta ejecución de prueba y la función que contiene las pruebas. La expectfunción le dice a QUnit cuántas pruebas hay en ejecución. Si llamamos muy pocos o demasiados, se produce un error.

    La okfunción realiza la prueba de la expresión. Se necesitan dos argumentos: un booleano que indica si la prueba fue exitosa y un mensaje.

    Las ejecuciones de pruebas se agregan a una sección de lista especial, que muestra el número total de pruebas, si cada prueba pasó o no y cuánto tiempo tomaron las pruebas.

    Una prueba unitaria real

    Los complementos de WordPress complican las pruebas mediante el uso de una combinación de PHP y JavaScript. Incluso pasar un valor simple de PHP a JavaScript resulta complicado.

    La siguiente función encuentra una preferencia de WordPress con la get_optionfunción y crea una variable de JavaScript con el valor resultante.

    function getOption($myOption, $myVariable) { if (get_option($myOption) != "") { ?script type="text/javascript" ?php echo($myVariable); ? = ?php echo(get_option($myOption)); ?; php }}

    Ahora lo llamaremos para obtener el nombre del blog y lo configuraremos en una variable llamada myBlogName.

    getOption("blogname", "myBlogName");

    Pequeñas funciones de ayuda como estas unen tu complemento, pero siempre me preocupan. ¿Accedí a la variable JavaScript con el nombre correcto o lo escribí mal? ¿Usé el mismo nombre dos veces? Una simple prueba unitaria hace que todas estas preocupaciones desaparezcan.

    function wpPrefTest() { test('Get access to WordPress preferences', function() { expect(1); ok(myBlogName, 'The variable (myBlogName) should be available.'); });}

    Esta prueba unitaria comprueba si la variable myBlogNameexiste. También podríamos buscar un valor específico o compararlo con algo más de la aplicación.

    Una vez que tengas esta prueba unitaria, nunca tendrás que preocuparte por obtener el nombre del blog. Siempre estará ahí y lo descubrirás rápidamente si alguna vez lo rompes.

    Integrando QUnit con WordPress

    Las pruebas en entornos de desarrollo especiales no son precisas. Quería agregar QUnit directamente a mi calendario, pero no quería aumentar el tamaño de la página. La solución es un parámetro de URL y un poco de PHP para incluir QUnit sólo cuando lo necesito:

     

    wp_enqueue_script( "qunit", path_join(WP_PLUGIN_URL, basename( dirname( __FILE__ ) )."/lib/qunit.js"), array( 'jquery' ) );wp_enqueue_script( "edcal-test", path_join(WP_PLUGIN_URL, basename( dirname( __FILE__ ) )."/edcal_test.js"), array( 'jquery' ) );

    Esto le indica a WordPress que incluya QUnit JavaScript y mis pruebas unitarias de edcal_test.js. Podría haber incrustado la referencia del script directamente en mi página, pero podría haber tenido problemas si otros complementos en la misma página usan QUnit.

    Puedes ver el código fuente completo aquí .

    El siguiente paso fue asegurarme de que estos scripts se carguen sólo cuando los necesite. Para hacer esto, envolví el código en una verificación de un parámetro de URL:

    if ($_GET['qunit']) { wp_enqueue_script( "qunit", path_join(WP_PLUGIN_URL, basename( dirname( __FILE__ ) )."/lib/qunit.js"), array( 'jquery' ) ); wp_enqueue_script( "edcal-test", path_join(WP_PLUGIN_URL, basename( dirname( __FILE__ ) )."/edcal_test.js"), array( 'jquery' ) );}

    Esto carga los scripts solo si estoy ejecutando pruebas unitarias y todo lo demás en el complemento permanece igual. Puede ejecutar las pruebas unitarias en cualquier momento simplemente agregándolas qunit=trueal final de la URL. Eso es bueno porque mis pruebas unitarias realmente cambian lo que sucede en el blog.

    Puede ejecutar las pruebas unitarias del Calendario Editorial en su navegador ahora mismo . Desplácese hacia abajo para ver los resultados de las pruebas unitarias en la parte inferior de la página.

    PHP se asegura de que mis scripts lleguen al navegador. El último paso es llamarlos desde mi JavaScript. Una vez más, quiero llamarlos sólo si estamos en modo de prueba unitaria. Entonces, agrego una pequeña función para obtener los parámetros de la URL:

    getUrlVars: function() { var vars = [], hash; var hashes = window.location.href.slice(window.location.href.indexOf('?') + 1).split(''); for (var i = 0; i hashes.length; i++) { hash = hashes[i].split('='); vars.push(hash[0]); vars[hash[0]] = hash[1]; } return vars;}

    Y luego llamo a mis pruebas unitarias si el parámetro QUnit está ahí:

    jQuery(document).ready(function() { if (edcal.getUrlVars().qunit) { edcal_test.runTests(); }});

    Esto garantiza que llamemos a las pruebas unitarias solo si están disponibles.

    El último paso es configurar un espacio para la salida de la prueba unitaria. QUnit escribe los resultados de sus pruebas en etiquetas especialmente designadas en su página HTML. Puede incrustar estas etiquetas directamente en su salida HTML, pero como deben estar allí solo cuando QUnit está activo, creo el HTML en JavaScript.

    jQuery('head').append('link');css = jQuery('head').children(':last');css.attr({ rel: 'stylesheet', type: 'text/css', href: '../wp-content/plugins/edcal/lib/qunit.css'});jQuery('#wpbody-content .wrap').append('div/div');jQuery('#edcal-qunit').append( 'h1WordPress Editorial Calendar Unit Tests/h1' + 'h2/h2' + 'div/div' + 'h2/h2' + 'ol/ol' + 'divtest markup/div');

    QUnit necesita una etiqueta de lista, un par de divs y una hoja de estilo.

     

    Ahora estamos listos para escribir nuestra primera prueba.

    La primera prueba unitaria

    Las primeras pruebas unitarias del calendario desplazan el calendario hacia arriba y hacia abajo y se aseguran de que veamos la cantidad correcta de días.

    moveTests: function() { var curSunday = edcal.nextStartOfWeek(Date.today()).add(-1).weeks(); edcal.moveTo(Date.today()); test('Move to today and check visible dates', function() { expect(2); ok(edcal_test.getFirstDate().equals(curSunday.clone()), 'firstDate should match ' + curSunday); ok(edcal_test.getLastDate().equals( curSunday.clone().add(edcal.weeksPref).weeks().add(-1).days()), 'lastDate should match ' + curSunday); });}

    Nuestra primera prueba mueve el calendario a hoy y verifica si el primer y el último día son lo que esperamos. Configuramos una variable, movemos el calendario y comenzamos la prueba llamando a la testfunción. Todo sobre las islas canarias

    En este caso queremos asegurarnos de que las fechas sean correctas, por lo que comparamos la fecha del calendario con la que esperamos y luego pasamos el resultado a la okfunción. La prueba tiene éxito si coinciden y falla si no lo hacen.

    Esta prueba puede parecer simple, pero suceden muchas cosas bajo el capó. Estamos probando el manejo de fechas, el dibujo y la aritmética fundamental del calendario.

    Las pruebas unitarias pueden hacer cualquier cosa. Las pruebas unitarias del Calendario editorial de WordPress automatizan el complemento como un robot. Cubren todo lo que un usuario podría hacer con el calendario.

    Qué hacer la prueba unitaria

    Escribo muchas más pruebas unitarias para JavaScript que para lenguajes compilados. En Java y C++, el compilador detecta muchos de mis errores, mientras que JavaScript te permite pasar a stringcuando querías pasar a numbery te permite llamar a una función con dos argumentos cuando necesita tres.

    Aquí está la lista básica de áreas que pruebo en aplicaciones JavaScript:

    • Pruebas que garantizan que el programa haga lo que debe hacer . Estas pruebas garantizan que la funcionalidad básica siga funcionando; no prueban las interacciones. (El calendario le permite arrastrar y soltar publicaciones, pero escribir pruebas unitarias para arrastrar y soltar no tendría sentido; en cambio, nos centraríamos en lo que sucede después del evento de colocación).
    • Pruebas que garantizan que el programa no haga lo que no debe hacer. Estas pruebas garantizan que el programa falla correctamente cuando recibe basura.
    • Una prueba unitaria para cada error importante que he encontrado. Estas pruebas garantizan que ninguno de estos errores vuelva a aparecer.

    Las API y otros límites claros en el código se prestan bien para las pruebas unitarias, al igual que las funciones de utilidad que usted llama desde muchos lugares de la aplicación. Con el calendario, esto significa probar los movimientos del calendario y probar cómo creamos y modificamos publicaciones en WordPress, así:

    1. Mueve el calendario y consulta las fechas;
    2. Crea una publicación y asegúrate de que se haya creado correctamente;
    3. Edite la publicación que acabamos de crear y asegúrese de que se guarde correctamente;
    4. Mueva la publicación y asegúrese de que aparezca en la fecha correcta;
    5. Mueva la publicación desde dos lugares al mismo tiempo y asegúrese de que recibamos el mensaje de advertencia adecuado;
    6. Elimina la publicación del servidor y asegúrate de que ya no esté allí.

    La penúltima prueba cubre una condición de error en la que dos personas mueven el mismo poste al mismo tiempo. Las pruebas unitarias funcionan bien para este tipo de error, porque el tipo de error es difícil de probar y es menos probable que las pruebas manuales descubran problemas.

     

    Para su propia aplicación, debe tener al menos una prueba unitaria para cada operación de cambio de datos que puedan realizar los usuarios. También me gusta agregarlos para todos los lugares donde un usuario puede obtener datos. Puede parecer mucho trabajo, pero puedes reducirlo escribiendo pruebas únicas que cubran múltiples áreas.

    Pruebas unitarias asincrónicas

    Muchas de estas pruebas unitarias combinadas realizan llamadas AJAX. QUnit proporciona una función especial para manejar AJAX llamada asyncTest. Esta función funciona igual test, pero detiene la ejecución de la prueba al final de la función. El marco QUnit espera hasta que se complete su llamada AJAX y usted llame a la startfunción antes de reiniciar la ejecución de prueba.

    La asyncTestfunción maneja todas las pruebas que editan publicaciones del calendario, incluida la eliminación de la publicación al final:

    asyncTest('Delete the post created for testing', function() { expect(1); edcal.deletePost(edcal_test.post.id, function(res) { equals(jQuery('#post-' + res.post.id).length, 0, 'The post should now be deleted from the calendar.'); start(); });});

    Cuando reinicia el marco de prueba, puede llamar a más pruebas. Llamar a la siguiente función de prueba al final de la anterior las encadena y admite llamar a todas sus pruebas con solo una llamada a la primera función.

    Estas pruebas, que llaman a AJAX, garantizan que la integración entre JavaScript en el lado del cliente y PHP en el back-end funcione correctamente.

    Eso no es una prueba unitaria

    Cuando aprendí por primera vez a escribir pruebas unitarias en C++, la regla era la siguiente: una sola prueba solo debe llamar al código de un único módulo o archivo CPP. Es decir, una prueba unitaria debe probar una unidad de código.

    Cambiar publicaciones de pruebas unitarias viola esa regla. En lugar de simplemente probar JavaScript, realmente estoy probando JavaScript, PHP, WordPress y MySQL, todo al mismo tiempo. Eso lo convierte en una prueba de integración automatizada.

    Las pruebas de integración no son pruebas unitarias tradicionales, pero funcionan bien para los complementos de WordPress. Cuando creo una publicación, sabré que el código AJAX de mi complemento funciona tan bien como el código JavaScript. Cubrir una mayor parte de la aplicación con menos pruebas hace que sea más fácil centrarme en lo que debería probar.

    Qué no hacer en la prueba unitaria

    Podrías escribir pruebas unitarias para siempre, pero algunas son más útiles que otras. Aquí hay algunas pautas.

     

    • No realice pruebas unitarias de la interfaz de usuario. La prueba debe realizarse por sí sola. No puede esperar a que hagas clic en un botón o mires algo para asegurarte de que aparece correctamente.
    • No realice pruebas unitarias de rendimiento. Las pruebas toman una cantidad de tiempo variable en diferentes máquinas y navegadores. No escriba pruebas unitarias que dependan de que una función se devuelva en un período de tiempo determinado.
    • No realice pruebas unitarias de código de otros proyectos. Agregar pruebas unitarias para WordPress o un complemento jQuery del que dependa puede resultar tentador, pero rara vez vale la pena. Si desea contribuir con pruebas unitarias a WordPress.org, eso es genial, pero sus pruebas unitarias deben verificar que su complemento funcione.

    El Calendario Editorial tiene 26 pruebas unitarias, con aproximadamente 3500 líneas de código. Puede que no parezca mucho, pero han guardado muchos de mis lanzamientos.

    Las pruebas unitarias me salvaron el trasero

    No agregué pruebas unitarias hasta la decimotercera versión de mi complemento. Para entonces, el calendario tenía unos cientos de usuarios y estaba creciendo rápidamente. Mi complemento estaba funcionando y me estaba acercando a la versión 1.0.

    En lugar de agregar nuevas funciones, adopté un nuevo marco, agregué un código especial para cargarlo, escribí 381 líneas de pruebas unitarias e integré todo esto en el complemento. Parece mucho trabajo, pero me salvó el trasero.

    Justo antes del lanzamiento, escribí un código PHP de apariencia inofensiva como el siguiente para obtener los datos JSON que representaban un conjunto de publicaciones para mostrar en el calendario:

    function edcal_postJSON($post) { setup_postdata($post); ? { "date" : "?php the_time('d') ??php the_time('m') ??php the_time('Y') ?", "title" : ?php echo($this-edcal_json_encode(get_the_title())); ?, "author" : ?php echo($this-edcal_json_encode(get_the_author())); ? }, ?php}function edcal_posts() { header("Content-Type: application/json"); global $post; $args = array( 'posts_per_page' = -1, 'post_status' = "publishfuturedraft", 'post_parent' = null // any parent ); $myposts = query_posts($args); ?[ ?php $size = sizeof($myposts); for($i = 0; $i $size; $i++) { $post = $myposts[$i]; edcal_postJSON($post, $i $size - 1); } ? ] ?php}

    Ejecuté el código y todo funcionó. Estaba a punto de lanzar la nueva versión, pero primero ejecuté mis pruebas unitarias para asegurarme. Ellos fallaron. ¿Puedes detectar el error? No lo hice.

    Estaba devolviendo una matriz JSON, pero el último elemento de la matriz tenía una coma al final. Eso es JSON no válido. Firefox lo acepta, pero Safari, Chrome e IE no. Casi envié un complemento roto a más de la mitad de mis usuarios.

    Ahora ejecuto las pruebas unitarias en todos los navegadores principales cada vez que lanzo una nueva versión. Cada vez que WordPress lanza una nueva versión, ejecuto las pruebas unitarias. WordPress 3.3 rompió el calendario y descubrí exactamente por qué en 15 segundos.

    Los complementos populares son complementos estables

    La mayoría de los complementos de WordPress son gratuitos y de código abierto, pero gratis no siempre significa barato. El costo total de propiedad de los complementos inestables es más de lo que la gente pagaría. Esa es una forma elegante de decir que los usuarios ejecutarán su complemento si se trata de una fiesta de errores.

    Mi complemento se hizo popular debido a sus características, pero la estabilidad lo mantuvo popular. La gente recuerda un lanzamiento con errores durante mucho tiempo. Si el Calendario Editorial elimina o corrompe publicaciones de un solo blog, miles de personas dejarían de usarlo. Y estarían justificados.

    Las pruebas unitarias agregan la estabilidad que necesita para admitir la multitud de navegadores, dispositivos móviles y rincones oscuros involucrados en cualquier aplicación JavaScript. Son fáciles de escribir y te devuelven la pena: porque tú encuentras los errores y tus usuarios no.

    (Alabama)Explora más en

    • WordPress
    • Codificación
    • javascript
    • Complementos
    • Técnicas (WP)





    Tal vez te puede interesar:

    1. ¿Deberían abrirse los enlaces en ventanas nuevas?
    2. 24 excelentes tutoriales de AJAX
    3. 70 técnicas nuevas y útiles de AJAX y JavaScript
    4. Más de 45 excelentes recursos y repositorios de fragmentos de código

    Escribir pruebas unitarias para complementos de WordPress

    Escribir pruebas unitarias para complementos de WordPress

    ¡Registro! Accesibilidad para diseñadores, con Stéphanie Walter Índice Lecturas adicionales sobre Smas

    programar

    es

    https://aprendeprogramando.es/static/images/programar-escribir-pruebas-unitarias-para-complementos-de-wordpress-793-0.jpg

    2024-05-20

     

    Escribir pruebas unitarias para complementos de WordPress
    Escribir pruebas unitarias para complementos de WordPress

    Si crees que alguno de los contenidos (texto, imagenes o multimedia) en esta página infringe tus derechos relativos a propiedad intelectual, marcas registradas o cualquier otro de tus derechos, por favor ponte en contacto con nosotros en el mail [email protected] y retiraremos este contenido inmediatamente

     

     

    Top 20