Para JavaScript, hay una p\u00e1gina sobre c\u00f3mo ejecutar pruebas QUnit<\/a> en el Manual, aunque se trata m\u00e1s de probar el c\u00f3digo JavaScript en el n\u00facleo de WordPress.<\/p>\n Si bien nada de esto est\u00e1 estandarizado para JavaScript en WordPress, podemos escribir excelentes pruebas unitarias utilizando el conjunto de pruebas Jest. En este art\u00edculo, aprenderemos c\u00f3mo escribir pruebas unitarias de JavaScript para un complemento de ejemplo que carga 5 publicaciones a trav\u00e9s de la API REST de WP utilizando la En el pasado, escribir pruebas unitarias de JavaScript implicaba configurar Mocha para ejecutar pruebas, Chai para hacer afirmaciones y Sinon para simular funciones y espiarlas. Si bien ofrecen una gran flexibilidad, es mucho m\u00e1s complejo trabajar con tres paquetes que con uno. Jest<\/a> proporciona todo esto en un solo paquete:<\/p>\n Para mantener este art\u00edculo centrado en las pruebas con Jest, hay una configuraci\u00f3n adicional externa al proceso de prueba como Babel o Webpack que no se tratar\u00e1 aqu\u00ed. Todo esto se puede encontrar en el repositorio de WP Jest Tests<\/a> que acompa\u00f1a a este art\u00edculo. Para mantener las cosas contextuales, cada secci\u00f3n se vincular\u00e1 a uno de los archivos relevantes que escribiremos.<\/p>\n El PHP para el complemento de ejemplo<\/a> que usaremos para aprender a escribir las pruebas unitarias de JavaScript es bastante est\u00e1ndar. Las \u00fanicas l\u00edneas interesantes son aquellas cuando ponemos en cola nuestro archivo JavaScript y agregamos un script en l\u00ednea para pasarle variables:<\/p>\n Despu\u00e9s de enquear nuestro archivo JavaScript, agregamos una variable global Primero tendremos que inicializar Edite el archivo package.json<\/a> que se cre\u00f3 y agregue una nueva entrada para ejecutar nuestras pruebas en la Este ser\u00e1 el comando que usaremos para decirle a Jest que ejecute nuestras pruebas unitarias de JavaScript. Esta es una ejecuci\u00f3n \u00fanica, pero Jest tambi\u00e9n admite la visualizaci\u00f3n de archivos, por lo que puede ingresar uno adicional:<\/p>\n Ahora instale Jest como una dependencia de desarrollo ejecutando<\/p>\n Mientras se instala, cree un archivo llamado Repasemos cada uno:<\/p>\n Seguramente not\u00f3 la referencia: este es un token especial que es reemplazado por Jest con la ra\u00edz de su proyecto, que generalmente es la ubicaci\u00f3n de su archivo Profundizaremos en las siguientes dos secciones, pero primero, cree la carpeta y estos dos archivos a los que se hace referencia anteriormente:<\/p>\n Si, como este complemento, usa Webpack para compilar todo, incluidos los estilos, y est\u00e1 importando el necesita usar styleMock.js<\/a> para simular archivos SASS al importarlos en nuestro archivo JavaScript; de lo contrario, Jest se bloquear\u00e1 porque no podr\u00e1 resolver el m\u00f3dulo. No necesita mucho para este archivo, solo agregue<\/p>\n Jest usar\u00e1 este simulacro cada vez que encuentre una Trabajemos ahora en el archivo globals.js<\/a>. Una de las ventajas de usar Jest es que ya viene con una Cree una carpeta Esto declarar\u00e1 y simular\u00e1 algunos objetos y m\u00e9todos que luego usar\u00e1 en sus pruebas. El \u00faltimo es de especial inter\u00e9s.<\/p>\n Esta es la variable global que escribimos usando El complemento de WordPress tiene un solo archivo JavaScript main.js<\/a> en una Vas a exportar la funci\u00f3n que hace todo el trabajo:<\/p>\n para que puedas usarlo en tus pruebas en Jest.<\/p>\n \u00a1Ahora puedes empezar a escribir pruebas! Jest puede encontrar pruebas de muchas maneras:<\/p>\n Cree la A continuaci\u00f3n, borramos todos los simulacros, para que nunca ejecutemos simulacros sucios que contengan valores de pruebas anteriores. Hacer esto puede generar errores ya que, por ejemplo, si estamos espiando cu\u00e1ntas veces se llam\u00f3 a una funci\u00f3n simulada, podr\u00edamos obtener una lectura incorrecta si no borramos el simulacro entre prueba y prueba:<\/p>\n La primera prueba que escribiremos hace afirmaciones b\u00e1sicas cuando algunas cosas fallan. Por ejemplo, si la variable global En este c\u00f3digo,<\/p>\n La primera prueba no define nada, por La segunda prueba define El siguiente conjunto de pruebas comienza con<\/p>\n y dentro de esto, tenemos otra funci\u00f3n de desmontaje:<\/p>\n a diferencia Simulamos la primera Promesa que se resuelve en la respuesta, y la segunda en una representaci\u00f3n JSON de los datos. Estos datos son similares a los que obtenemos de la API REST de WP. Dado que nuestro c\u00f3digo solo necesita el t\u00edtulo y el enlace, nos estamos burlando de eso.<\/p>\n Ahora podemos escribir la prueba usando el archivo simulado Desde el principio, esto es diferente: la funci\u00f3n an\u00f3nima pasada a El global Llamamos El resto son m\u00e1s afirmaciones para garantizar que se Ahora puedes escribir<\/p>\n y Jest ejecutar\u00e1 las pruebas unitarias de JavaScript para su complemento de WordPress<\/p>\nfetch<\/code>funci\u00f3n de JavaScript y las representa en un determinado elemento DOM en la p\u00e1gina.<\/p>\nBeneficios de usar Jest para pruebas unitarias de JavaScript en WordPress<\/h2>\n
\n
describe<\/code>y it<\/code>otest<\/code><\/li>\nexpect<\/code>y toBe<\/code>, toHaveLength<\/code>y muchas m\u00e1s<\/li>\nAntes de continuar<\/h3>\n
Descripci\u00f3n general del lado de PHP<\/h2>\n
$initial_state = rawurlencode( wp_json_encode( array(\n 'restUrl' => esc_url_raw( rest_url() ),\n 'posts' => 5,)) );\nwp_enqueue_script( \n 'wp-jest-tests',\n plugins_url( 'front.js', __FILE__ ),\n array(),\n $plugin_version,\n true\n);\nwp_add_inline_script(\n 'wp-jest-tests',\n 'window.wpJestTests = JSON.parse(decodeURIComponent(\"'. $initial_state. '\"));',\n 'before'\n);<\/code><\/pre>\nwpJestTests<\/code>con wp_add_inline_script()<\/code>. Esta variable es particularmente interesante y dif\u00edcil de manejar porque es externa a nuestro archivo JavaScript y tendremos que simularla en nuestras pruebas.<\/p>\nConfigurar pruebas Jest<\/h2>\n
npm<\/code>nuestro proyecto de complemento para poder instalar Jest con \u00e9l. Navegue en la l\u00ednea de comando a su carpeta de complementos y ejecute:<\/p>\nnpm init<\/code>y siga la serie de indicaciones aqu\u00ed<\/p>\nscripts<\/code>secci\u00f3n:<\/p>\n\"test\": \"jest\"<\/code><\/p>\n\"test-watch\": \"jest --watch\"<\/code><\/p>\nnpm install -D jest<\/code><\/p>\njest.config.js<\/code>. Esto mantendr\u00e1 toda la configuraci\u00f3n necesaria. Agregue lo siguiente:<\/p>\nmodule.exports = {\n verbose: true,\n setupFiles: [\n '\/__mocks__\/globals.js'\n ],\n moduleNameMapper: {\n '.(css|less|sass|scss)$': '\/__mocks__\/styleMock.js'\n }\n};<\/code><\/pre>\n\n
verbose<\/code>: indica si se debe informar cada prueba individual durante la ejecuci\u00f3n. Todos los errores tambi\u00e9n se seguir\u00e1n mostrando en la parte inferior despu\u00e9s de la ejecuci\u00f3n. Tenga en cuenta que si solo se est\u00e1 ejecutando un archivo de prueba, el valor predeterminado es true<\/code>.<\/li>\nsetupFiles<\/code>: una lista de rutas a m\u00f3dulos que ejecutan alg\u00fan c\u00f3digo para configurar o configurar el entorno de prueba. Cada archivo de configuraci\u00f3n se ejecutar\u00e1 una vez por archivo de prueba. Dado que cada prueba se ejecuta en su propio entorno, estos scripts se ejecutar\u00e1n en el entorno de prueba inmediatamente antes de ejecutar el c\u00f3digo de prueba. Usaremos esto para declarar variables globales renderizadas por PHP y WordPress con comandos como wp_add_inline_script<\/code>o wp_localize_script<\/code>.<\/li>\nmoduleNameMapper<\/code>: este es un mapa de expresiones regulares a nombres de m\u00f3dulos (o matrices de nombres de m\u00f3dulos) que permiten extraer recursos est\u00e1ticos, como im\u00e1genes o estilos con un solo m\u00f3dulo.<\/li>\n<\/ul>\npackage.json<\/code>.<\/p>\n\n
__mocks__<\/code><\/li>\nstyleMock.js<\/code>yglobals.js<\/code><\/li>\n<\/ul>\nImportaci\u00f3n de estilos simulados para pruebas Jest<\/h2>\n
.scss<\/code>archivo en el .js<\/code>archivo:<\/p>\nimport '.\/main.scss';<\/code><\/pre>\n.scss<\/code>importaci\u00f3n y los asignar\u00e1 al simulacro, permiti\u00e9ndole avanzar con las pruebas sin preocuparse por los estilos.<\/p>\nConfigurar globales para Jest<\/h2>\n
jsdom<\/code>implementaci\u00f3n de est\u00e1ndares web de JavaScript puro ya configurada, que simula un entorno DOM como si estuviera en el navegador, y lo usaremos para simular elementos DOM. para nuestras pruebas.<\/p>\n__mocks__<\/code>y un globals.js<\/code>archivo dentro de ella. Agregue esto al archivo:<\/p>\nimport { JSDOM } from 'jsdom';\nconst dom = new JSDOM();\nglobal.document = dom.window.document;\nglobal.window = dom.window;\nglobal.window.wpJestTests = undefined;<\/code><\/pre>\nglobal.window.wpJestTests = undefined;<\/code><\/pre>\nwp_add_inline_script<\/code>. Debe simularlo como una variable global para poder usarlo en sus pruebas.<\/p>\nDescripci\u00f3n general del archivo JavaScript<\/h2>\n
\/src<\/code>carpeta. Esto luego se transpila y se genera en un \/js\/front.js<\/code>archivo que es lo que cargar\u00e1 el PHP. El JavaScript carga cinco publicaciones de WordPress usando fetch<\/code>, una funci\u00f3n est\u00e1ndar de JavaScript, a trav\u00e9s de la API REST de WP e inserta su t\u00edtulo, con un enlace a la publicaci\u00f3n, en un archivo div.entry-content<\/code>.<\/p>\nexport const wpJestTestsInit =() => {<\/code><\/pre>\nEscribiendo pruebas unitarias de JavaScript con Jest, \u00a1por fin!<\/h2>\n
\n
test.js<\/code><\/li>\nmain.test.js<\/code><\/li>\n.js<\/code>archivos ubicados en una carpeta llamada__tests__<\/code><\/li>\n<\/ul>\n__tests__<\/code>carpeta y dentro de ella, un archivo front.test.js<\/code>. Puede ver el archivo JavaScript terminado para las pruebas de Jest<\/a> en el repositorio complementario. Ve\u00e1moslo en bloques. La primera l\u00ednea importa el archivo JS que queremos probar:<\/p>\nimport { wpJestTestsInit } from '..\/src\/main';<\/code><\/pre>\nafterEach(() => {\n jest.clearAllMocks();\n} );<\/code><\/pre>\nwpJestTests<\/code>con la que est\u00e1bamos escribiendo wp_add_inline_script<\/code>no se escribi\u00f3 por alguna raz\u00f3n:<\/p>\ndescribe( 'Initialization', () => {\n test( 'if wpJestTests is undefined, nothing happens', () => {\n expect( wpJestTestsInit() ).toBe( false );\n } );\n\n test( 'if .entry-content is missing, nothing happens', () => {\n wpJestTests = { posts: 5 };\n const mockQuerySelector = jest.spyOn( document, 'querySelector') .mockImplementation( () => undefined );\n expect( wpJestTestsInit() ).toBe( false );\n expect( mockQuerySelector ).toHaveBeenCalledTimes( 1 );\n } );\n} );<\/code><\/pre>\n\n
describe<\/code>crea un grupo compuesto por varias pruebas relacionadas<\/li>\ntest<\/code>es lo que realmente realiza una prueba<\/li>\nexpect<\/code>envuelve nuestro sujeto de prueba proporcionando acceso a una serie de "coincidencias" que le permiten hacer diferentes afirmaciones sobre su contenido<\/li>\ntoBe<\/code>es uno de estos emparejadores. Jest tiene muchos comparadores incluidos<\/a>, e incluso hay otros que puedes agregar con un paquete de terceros<\/a>.<\/li>\n<\/ul>\nwpJestTests<\/code>lo que su valor ser\u00e1 el que defini\u00f3 en globals.js<\/code>. Como es undefined<\/code>, no podemos trabajar, por lo que queremos confirmar que la funci\u00f3n regresa sin hacer nada.<\/p>\nwpJestTests<\/code>y simula el document.querySelector<\/code>m\u00e9todo para devolver undefined<\/code>lo que devolver\u00eda si no pudiera encontrar un elemento en el DOM. En tal caso, queremos confirmar que estamos regresando sin hacer nada, y que nuestra funci\u00f3n de simulaci\u00f3n document.querySelector<\/code>fue llamada una vez.<\/p>\nMock fetch en las pruebas de Jest<\/h2>\n
describe( 'Fetch posts', () => {<\/code><\/pre>\nafterAll( () => {\n global.fetch.mockClear();\n delete global.fetch;\n});<\/code><\/pre>\nafterEach<\/code>de esto se ejecutar\u00e1 despu\u00e9s de que se hayan ejecutado todas las pruebas dentro de este describe<\/code>bloque. Dado que nuestro archivo JavaScript se usa fetch<\/code>para cargar las publicaciones, debemos verificar que se haya llamado y haya devuelto lo que solicitamos, por lo que vamos a simular la fetch<\/code>funci\u00f3n:<\/p>\nglobal.fetch = jest.fn().mockImplementation(\n () => Promise.resolve({\n ok: true,\n status: 200,\n json: () => Promise.resolve( [\n {\n link: 'test-1',\n title: { rendered: 'Post 1' }\n },\n {\n link: 'test-2',\n title: { rendered: 'Post 2' }\n },\n {\n link: 'test-3',\n title: { rendered: 'Post 3' }\n },\n {\n link: 'test-4',\n title: { rendered: 'Post 4' }\n },\n {\n link: 'test-5',\n title: { rendered: 'Post 5' }\n },\n ] ),\n })\n);<\/code><\/pre>\nPrueba de integraci\u00f3n de JavaScript con Jest en c\u00f3digo as\u00edncrono que usa fetch<\/h2>\n
fetch<\/code>. Hay una gran diferencia con esta prueba en comparaci\u00f3n con otras pruebas unitarias de JavaScript: esta es una prueba de integraci\u00f3n. Las pruebas anteriores exploradas aqu\u00ed simplemente aseguraron que un componente funcionaba bien. Verificamos que si la variable global de estado inicial no estaba definida, nuestro componente no se renderizar\u00eda. Esto es diferente porque vamos a probar c\u00f3mo funciona todo el sistema cuando se define la variable de estado inicial, activando as\u00ed una transacci\u00f3n de datos y finalmente insertando los t\u00edtulos de las publicaciones con sus enlaces en el documento.<\/p>\ntest<\/code>recibe un done<\/code>par\u00e1metro. Esta es en realidad una funci\u00f3n que se llamar\u00e1 cuando finalicemos la prueba. Jest esperar\u00e1 hasta done<\/code>que se llame antes de terminar la prueba. Si done<\/code>nunca se llama, la prueba fallar\u00e1 con un error de tiempo de espera. Eso es interesante para nosotros ya que estamos probando c\u00f3digo que involucra fetch<\/code>, que es una funci\u00f3n as\u00edncrona.<\/p>\ntest( 'if posts are fetch, inserts them', done => {\n wpJestTests = { posts: 5 };\n const mockClassListAdd = jest.fn();\n const divElem = {\n tagName: 'DIV',\n classList: { add: mockClassListAdd },\n innerHTML: ''\n };\n const mockQuerySelector = jest.spyOn( document, 'querySelector') .mockImplementation( () => divElem );\n\n expect( wpJestTestsInit() ).toBe( true );\n\n process.nextTick(() => {\n expect( mockQuerySelector ).toHaveBeenCalledTimes( 1 );\n expect( global.fetch ).toHaveBeenCalledTimes( 1 );\n expect( mockClassListAdd ).toHaveBeenCalledTimes( 1 );\n expect( divElem.innerHTML.match( \/test-[1-5]\/g ).length ).toBe( 5 );\n\n done();\n });\n} );<\/code><\/pre>\nwpJestTests<\/code>est\u00e1 definido y nuestro simulado document.querySelector<\/code>ahora devuelve lo que se parece a un elemento HTML, con even classList<\/code>y su add<\/code>m\u00e9todo secundario.<\/p>\nwpJestTestsInit<\/code>y esperamos que termine correctamente. Ahora, dado que es as\u00edncrono, fetch<\/code>vamos a utilizar process.nextTick<\/code>desde Node.js.<\/a> En nextTick<\/code>Node.js es la cola que se ejecutar\u00e1 despu\u00e9s de que hayan finalizado todos los eventos en el bucle de eventos actual. Esto es genial porque todas nuestras promesas se resolver\u00edan entonces, que es exactamente lo que necesitamos para probar este c\u00f3digo que involucra fetch<\/code>.<\/p>\nquerySelector<\/code>encontr\u00f3 algo con lo que trabajar, que de fetch<\/code>hecho se llam\u00f3, que se agreg\u00f3 una clase a la lista y que los t\u00edtulos y enlaces de nuestras publicaciones se insertaron en el elemento HTML correspondiente. Una vez que todo est\u00e1 hecho, llamamos done<\/code>y nuestra prueba as\u00edncrona finaliza.<\/p>\nEjecute sus pruebas Jest<\/h2>\n
npm run test<\/code><\/p>\n
![\"Pruebas](\"https:\/\/wordpress.mediadoma.com\/wp-content\/uploads\/2022\/01\/post-157897-61e6c3c169e87.png\")
<\/a><\/p>\n