Cómo probar sus aplicaciones React con la biblioteca de pruebas React

 

 

 

  • SmashingConf Nueva York 2024

  • Índice
    1. Por qué deberías probar tu código
    2. Tipos de pruebas automatizadas
    3. ¿Por qué utilizar la biblioteca de pruebas React?
    4. Configuración del proyecto
    5. Probar y crear la página de índice de la lista de tareas pendientes

    Las pruebas dan confianza en el código escrito. En el contexto de este artículo, "pruebas" significa "pruebas automatizadas". Sin pruebas automatizadas, es mucho más difícil garantizar la calidad de una aplicación web de gran complejidad. Los fallos causados ​​por las pruebas automatizadas pueden provocar más errores en la producción. En este artículo, mostraremos cómo los desarrolladores de React pueden comenzar a probar rápidamente su aplicación con la Biblioteca de pruebas de React (RTL).

     

    Hoy, discutiremos brevemente por qué es importante escribir pruebas automatizadas para cualquier proyecto de software y arrojaremos luz sobre algunos de los tipos comunes de pruebas automatizadas. Crearemos una aplicación de lista de tareas pendientes siguiendo el enfoque de desarrollo basado en pruebas (TDD). Le mostraré cómo escribir pruebas unitarias y funcionales y, en el proceso, le explicaré qué son los simulacros de código burlándose de algunas bibliotecas. Usaré una combinación de RTL y Jest, los cuales vienen preinstalados en cualquier proyecto nuevo creado con Create-React-App (CRA).

    Para seguir adelante, necesita saber cómo configurar y navegar por un nuevo proyecto de React y cómo trabajar con el administrador de paquetes de hilo (o npm). También se requieren conocimientos de Axios y React-Router .

    Mejores prácticas de reacción

    React es una fantástica biblioteca de JavaScript para crear interfaces de usuario ricas. Proporciona una excelente abstracción de componentes para organizar sus interfaces en un código que funcione bien, y hay prácticamente cualquier cosa para la que pueda usarlo.Lea un artículo relacionado sobre React →

    Por qué deberías probar tu código

    Antes de enviar su software a los usuarios finales, primero debe confirmar que funciona como se esperaba. En otras palabras, la aplicación debe cumplir con las especificaciones de su proyecto.

     

    Así como es importante probar nuestro proyecto en su totalidad antes de enviarlo a los usuarios finales, también es esencial seguir probando nuestro código durante la vida útil de un proyecto. Esto es necesario por varias razones. Podemos realizar actualizaciones a nuestra aplicación o refactorizar algunas partes de nuestro código. Una biblioteca de terceros puede sufrir un cambio importante. Incluso el navegador que ejecuta nuestra aplicación web puede sufrir cambios importantes. En algunos casos, algo deja de funcionar sin motivo aparente; las cosas podrían salir mal inesperadamente. Por lo tanto, es necesario probar nuestro código periódicamente durante la vida útil de un proyecto.

    A grandes rasgos, existen pruebas de software manuales y automatizadas. En una prueba manual, un usuario real realiza alguna acción sobre nuestra aplicación para comprobar que funcionan correctamente. Este tipo de prueba es menos confiable cuando se repite varias veces porque es fácil que el evaluador pierda algunos detalles entre las ejecuciones de la prueba.

    Sin embargo, en una prueba automatizada, una máquina ejecuta un script de prueba. Con un script de prueba, podemos estar seguros de que cualquier detalle que establezcamos en el script permanecerá sin cambios en cada ejecución de prueba.

    Este tipo de prueba nos brinda la ventaja de ser predecible y rápida, de modo que podemos encontrar y corregir errores en nuestro código rápidamente.

    Habiendo visto la necesidad de probar nuestro código, la siguiente pregunta lógica es: ¿qué tipo de pruebas automatizadas deberíamos escribir para nuestro código? Repasemos rápidamente algunos de ellos.

    Tipos de pruebas automatizadas

    Existen muchos tipos diferentes de pruebas de software automatizadas. Algunas de las más comunes son las pruebas unitarias, las pruebas de integración, las pruebas funcionales, las pruebas de un extremo a otro, las pruebas de aceptación, las pruebas de rendimiento y las pruebas de humo.

    1. Test unitario
      En este tipo de test el objetivo es comprobar que cada unidad de nuestra aplicación, considerada de forma aislada, está funcionando correctamente. Un ejemplo sería probar que una función particular devuelve un valor esperado y proporcionar algunas entradas conocidas. Veremos varios ejemplos en este artículo.
    2. Prueba de humo
      Este tipo de prueba se realiza para comprobar que el sistema está en funcionamiento. Por ejemplo, en una aplicación React, podríamos simplemente renderizar el componente principal de nuestra aplicación y dar por terminado el día. Si se muestra correctamente, podemos estar bastante seguros de que nuestra aplicación se mostrará en el navegador.
    3. Prueba de integración
      Este tipo de prueba se lleva a cabo para verificar que dos o más módulos pueden funcionar bien juntos. Por ejemplo, puede ejecutar una prueba para verificar que su servidor y su base de datos se estén comunicando correctamente.
    4. Prueba funcional
      Existe una prueba funcional para verificar que el sistema cumple con su especificación funcional. Veremos un ejemplo más adelante.
    5. Prueba de un extremo a otro
      Este tipo de prueba implica probar la aplicación de la misma manera que se usaría en el mundo real. Puede utilizar una herramienta como cypress para pruebas E2E.
    6. Prueba de aceptación
      Generalmente la realiza el propietario de la empresa para verificar que el sistema cumple con las especificaciones.
    7. Prueba de rendimiento
      Este tipo de prueba se lleva a cabo para ver cómo funciona el sistema bajo una carga significativa. En el desarrollo frontend, esto generalmente se trata de qué tan rápido se carga la aplicación en el navegador.

    Hay más aquí si estás interesado.

     

    ¿Por qué utilizar la biblioteca de pruebas React?

    Cuando se trata de probar aplicaciones React, hay algunas opciones de prueba disponibles, de las cuales las más comunes que conozco son Enzyme y React Testing Library (RTL).

    RTL es un subconjunto de la familia de paquetes @testing-library . Su filosofía es muy simple. A sus usuarios no les importa si usa redux o contexto para la gestión del estado. Les importa menos la simplicidad de los ganchos ni la distinción entre clase y componentes funcionales. Solo quieren que tu aplicación funcione de cierta manera. Por lo tanto, no sorprende que el principio rector principal de la biblioteca de pruebas sea

    "Cuanto más se parezcan sus pruebas a la forma en que se utiliza su software, más confianza podrán brindarle".

    Entonces, hagas lo que hagas, ten en mente al usuario final y prueba tu aplicación tal como la usaría.

    Elegir RTL le ofrece una serie de ventajas. En primer lugar, es mucho más fácil empezar a utilizarlo. Cada nuevo proyecto de React iniciado con CRA viene con RTL y Jest configurados. Los documentos de React también la recomiendan como la biblioteca de prueba preferida. Por último, el principio rector tiene mucho sentido: la funcionalidad por encima de los detalles de implementación.

    Dejando eso de lado, comencemos a crear una aplicación de lista de tareas pendientes, siguiendo el enfoque TDD.

    Configuración del proyecto

    Abra una terminal, copie y ejecute el siguiente comando.

    # start new react project and start the servernpx create-react-app start-rtl cd start-rtl yarn start

    Esto debería crear un nuevo proyecto de React e iniciar el servidor en https://localhost:3000 . Con el proyecto en ejecución, abra una terminal separada, ejecútelo yarn testy luego presione a. Esto ejecuta todas las pruebas del proyecto en watchmodo. Ejecutar la prueba en modo de vigilancia significa que la prueba se volverá a ejecutar automáticamente cuando detecte un cambio en el archivo de prueba o en el archivo que se está probando. En el terminal de prueba, debería ver algo como la siguiente imagen:

    Superación de la prueba inicial. ( Vista previa grande )

    Deberías ver muchos verdes, lo que indica que la prueba que estamos realizando pasó con gran éxito.

    Como mencioné anteriormente, CRA configura RTL y Jest para cada nuevo proyecto de React. También incluye una prueba de muestra. Esta prueba de muestra es lo que acabamos de ejecutar.

    Cuando ejecuta el yarn testcomando, reaccionar-scripts llama a Jest para ejecutar la prueba. Jest es un marco de prueba de JavaScript que se utiliza para ejecutar pruebas. No lo encontrará en la lista package.json, pero puede hacer una búsqueda dentro yarn.lockpara encontrarlo. También puedes verlo en node_modules/.

     

    Jest es increíble por la gama de funciones que ofrece. Proporciona herramientas para hacer afirmaciones, burlarse, espiar, etc. Le recomiendo encarecidamente que realice al menos un recorrido rápido por la documentación. Hay mucho que aprender allí que no puedo mencionar en este breve artículo. Usaremos mucho Jest en las próximas secciones.

    Abierto package.json, veamos qué tenemos allí. La sección de interés es dependencies.

     "dependencies": { "@testing-library/jest-dom": "^4.2.4", "@testing-library/react": "^9.3.2", "@testing-library/user-event": "^7.1.2", ... },

    Tenemos los siguientes paquetes instalados específicamente para fines de prueba:

    1. @testing-library/jest-dom : proporciona comparadores de elementos DOM personalizados para Jest.
    2. @testing-library/react : proporciona las API para probar aplicaciones React.
    3. @testing-library/user-event : proporciona una simulación avanzada de las interacciones del navegador.

    Abre, App.test.jsechemos un vistazo a su contenido.

    import React from 'react';import { render } from '@testing-library/react';import App from './App';test('renders learn react link', () = { const { getByText } = render(); const linkElement = getByText(/learn react/i); expect(linkElement).toBeInTheDocument();});

    El rendermétodo de RTL representa el App /componente y devuelve un objeto desestructurado para la getByTextconsulta. Esta consulta encuentra elementos en el DOM por su texto para mostrar. Las consultas son las herramientas para encontrar elementos en el DOM. La lista completa de consultas se puede encontrar aquí . Todas las consultas de la biblioteca de pruebas se exportan mediante RTL, además de los métodos de renderizado, limpieza y acción. Puede leer más sobre estos en la sección API .

    El texto coincide con la expresión regular /learn react/i. La ibandera hace que la expresión regular no distinga entre mayúsculas y minúsculas. Buscamos expectel texto Learn Reacten el documento.

    Todo esto imita el comportamiento que un usuario experimentaría en el navegador al interactuar con nuestra aplicación.

    Comencemos a realizar los cambios que requiere nuestra aplicación. Abra App.jsy reemplace el contenido con el siguiente código.

    import React from "react";import "./App.css";function App() { return ( div className="App" header className="App-header" h2Getting started with React testing library/h2 /header /div );}export default App;

    Si todavía tiene la prueba ejecutándose, debería ver que la prueba falla. Quizás puedas adivinar por qué es así, pero volveremos a ello un poco más adelante. Ahora quiero refactorizar el bloque de prueba.

    Reemplace el bloque de prueba src/App.test.jscon el siguiente código:

    # use describe, it patterndescribe("App /", () = { it("Renders App / component correctly", () = { const { getByText } = render(App /); expect(getByText(/Getting started with React testing library/i)).toBeInTheDocument(); });});

    Esta refactorización no supone ninguna diferencia importante en la forma en que se ejecutará nuestra prueba. Prefiero el patrón describeand itporque me permite estructurar mi archivo de prueba en bloques lógicos de pruebas relacionadas. La prueba debería volver a ejecutarse y esta vez pasará. En caso de que no lo hayas adivinado, la solución para la prueba fallida fue reemplazar el learn reacttexto con Getting started with React testing library.

     

    En caso de que no tengas tiempo para escribir tus propios estilos, puedes copiar el siguiente en App.css.

    .App { min-height: 100vh; text-align: center;}.App-header { height: 10vh; display: flex; background-color: #282c34; flex-direction: column; align-items: center; justify-content: center; font-size: calc(10px + 2vmin); color: white;}.App-body { width: 60%; margin: 20px auto;}ul { padding: 0; display: flex; list-style-type: decimal; flex-direction: column;}li { font-size: large; text-align: left; padding: 0.5rem 0;}li a { text-transform: capitalize; text-decoration: none;}.todo-title { text-transform: capitalize;}.completed { color: green;}.not-completed { color: red;}

    Ya deberías ver el título de la página subir después de agregar este CSS.

    Considero que este es un buen punto para confirmar mis cambios y enviarlos a Github. La rama correspondiente es 01-setup .

    Continuamos con la configuración de nuestro proyecto. Sabemos que necesitaremos algo de navegación en nuestra aplicación, por eso necesitamos React-Router. También realizaremos llamadas API con Axios. Instalemos ambos.

    # install react-router-dom and axiosyarn add react-router-dom axios

    La mayoría de las aplicaciones React que crearás tendrán que mantener el estado. Hay muchas bibliotecas disponibles para gestionar el estado. Pero para este tutorial, usaré la API de contexto de React y el useContextgancho. Entonces, configuremos el contexto de nuestra aplicación.

    Cree un nuevo archivo src/AppContext.jse ingrese el contenido a continuación.

    import React from "react";export const AppContext = React.createContext({});export const AppProvider = ({ children }) = { const reducer = (state, action) = { switch (action.type) { case "LOAD_TODOLIST": return { ...state, todoList: action.todoList }; case "LOAD_SINGLE_TODO": return { ...state, activeToDoItem: action.todo }; default: return state; } }; const [appData, appDispatch] = React.useReducer(reducer, { todoList: [], activeToDoItem: { id: 0 }, }); return ( AppContext.Provider value={{ appData, appDispatch }} {children} /AppContext.Provider );};

    Aquí creamos un nuevo contexto con React.createContext({}), para el cual el valor inicial es un objeto vacío. Luego definimos un AppProvidercomponente que acepta childrenel componente. Luego envuelve esos elementos secundarios AppContext.Provider, haciendo así que el { appData, appDispatch }objeto esté disponible para todos los elementos secundarios en cualquier parte del árbol de renderizado. Anime en Español

    Nuestra reducerfunción define dos tipos de acciones.

     

    1. LOAD_TODOLISTque se utiliza para actualizar la todoListmatriz.
    2. LOAD_SINGLE_TODOque se utiliza para actualizar activeToDoItem.

    appDatay appDispatchambos regresan del useReduceranzuelo. appDatanos da acceso a los valores en el estado y appDispatchnos brinda una función que podemos usar para actualizar el estado de la aplicación.

    Ahora abra index.js, importe el AppProvidercomponente y envuélvalo App /con AppProvider /. Su código final debería verse como el que tengo a continuación.

    import { AppProvider } from "./AppContext";ReactDOM.render( React.StrictMode AppProvider App / /AppProvider /React.StrictMode, document.getElementById("root"));

    Wrapping App /inside AppProvider /pone AppContexta disposición de todos los componentes secundarios de nuestra aplicación.

    Recuerda que con RTL el objetivo es probar nuestra aplicación de la misma manera que un usuario real interactuaría con ella. Esto implica que también queremos que nuestras pruebas interactúen con el estado de nuestra aplicación. Por esa razón, también debemos ponerlo a AppProvider /disposición de nuestros componentes durante las pruebas. Veamos cómo hacer que eso suceda.

    El método de renderizado proporcionado por RTL es suficiente para componentes simples que no necesitan mantener el estado ni utilizar la navegación. Pero la mayoría de las aplicaciones requieren al menos uno de ambos. Por este motivo, ofrece una wrapperopción. Con este contenedor, podemos envolver la interfaz de usuario renderizada por el renderizador de prueba con cualquier componente que queramos, creando así un renderizado personalizado . Creemos uno para nuestras pruebas.

    Cree un nuevo archivo src/custom-render.jsy pegue el siguiente código.

    import React from "react";import { render } from "@testing-library/react";import { MemoryRouter } from "react-router-dom";import { AppProvider } from "./AppContext";const Wrapper = ({ children }) = { return ( AppProvider MemoryRouter{children}/MemoryRouter /AppProvider );};const customRender = (ui, options) = render(ui, { wrapper: Wrapper, ...options });// re-export everythingexport * from "@testing-library/react";// override render methodexport { customRender as render };

    Aquí definimos un Wrapper /componente que acepta algunos componentes secundarios. Luego envuelve a esos niños dentro AppProvider /y MemoryRouter /. El enrutador de memoria es

    Un Routerque mantiene el historial de tu “URL” en la memoria (no lee ni escribe en la barra de direcciones). Útil en pruebas y entornos sin navegador como React Native .

    Luego creamos nuestra función de renderizado, proporcionándole el Wrapper que acabamos de definir a través de su opción de contenedor. El efecto de esto es que cualquier componente que pasemos a la función de renderizado se renderiza dentro Wrapper /, teniendo así acceso a la navegación y al estado de nuestra aplicación.

    El siguiente paso es exportar todo desde @testing-library/react. Por último, exportamos nuestra función de renderizado personalizada como render, anulando así el renderizado predeterminado.

     

    Tenga en cuenta que incluso si estuviera usando Redux para la gestión del estado, se sigue aplicando el mismo patrón.

    Ahora asegurémonos de que nuestra nueva función de renderizado funcione. Impórtalo src/App.test.jsy úsalo para renderizar el App /componente.

    Abra App.test.jsy reemplace la línea de importación. Este

    import { render } from '@testing-library/react';

    debe convertirse

    import { render } from './custom-render';

    ¿Aún pasa la prueba? Buen trabajo.

    Hay un pequeño cambio que quiero hacer antes de concluir esta sección. Se vuelve agotador muy rápidamente tener que escribir const { getByText }y realizar otras consultas cada vez. Entonces, de ahora en adelante usaré el screenobjeto de la biblioteca de prueba DOM.

    Importe el objeto de pantalla desde nuestro archivo de renderizado personalizado y reemplace el describebloque con el siguiente código.

    import { render, screen } from "./custom-render";describe("App /", () = { it("Renders App / component correctly", () = { render(App /); expect( screen.getByText(/Getting started with React testing library/i) ).toBeInTheDocument(); });});

    Ahora estamos accediendo a la getByTextconsulta desde el objeto de pantalla. ¿Aún pasa tu prueba? Estoy seguro de que sí. Continuemos.

    Si sus pruebas no pasan, es posible que desee comparar su código con el mío. La rama correspondiente en este punto es 02-setup-store-and-render .

    Probar y crear la página de índice de la lista de tareas pendientes

    En esta sección, extraeremos elementos de tareas pendientes de https://jsonplaceholder.typicode.com/ . Nuestra especificación de componentes es muy simple. Cuando un usuario visita la página de inicio de nuestra aplicación,

    1. mostrar un indicador de carga que dice Fetching todosmientras se espera la respuesta de la API;
    2. muestra el título de 15 tareas pendientes en la pantalla una vez que regresa la llamada API (la llamada API devuelve 200). Además, el título de cada elemento debe ser un enlace que conduzca a la página de detalles de las tareas pendientes.

    Siguiendo un enfoque basado en pruebas, escribiremos nuestra prueba antes de implementar la lógica del componente. Antes de hacerlo necesitaremos tener el componente en cuestión. Así que continúa, crea un archivo src/TodoList.jse ingresa el siguiente contenido:

    import React from "react";import "./App.css";export const TodoList = () = { return ( div /div );};

    Como conocemos la especificación del componente, podemos probarlo de forma aislada antes de incorporarlo a nuestra aplicación principal. Creo que en este momento depende del desarrollador decidir cómo quiere manejar esto. Una razón por la que es posible que desee probar un componente de forma aislada es para no romper accidentalmente ninguna prueba existente y luego tener que apagar incendios en dos ubicaciones. Dejando eso de lado, escribamos ahora la prueba.

     

    Cree un nuevo archivo src/TodoList.test.jse ingrese el siguiente código:

    import React from "react";import axios from "axios";import { render, screen, waitForElementToBeRemoved } from "./custom-render";import { TodoList } from "./TodoList";import { todos } from "./makeTodos";describe("App /", () = { it("Renders TodoList / component", async () = { render(TodoList /); await waitForElementToBeRemoved(() = screen.getByText(/Fetching todos/i)); expect(axios.get).toHaveBeenCalledTimes(1); todos.slice(0, 15).forEach((td) = { expect(screen.getByText(td.title)).toBeInTheDocument(); }); });});

    Dentro de nuestro bloque de prueba, renderizamos el TodoList /componente y usamos la waitForElementToBeRemovedfunción para esperar a que el Fetching todostexto desaparezca de la pantalla. Una vez que esto sucede, sabemos que nuestra llamada API ha regresado. También comprobamos que una getllamada de Axios se haya disparado una vez. Finalmente, comprobamos que cada título de tarea pendiente se muestra en pantalla. Tenga en cuenta que el itbloque recibe una asyncfunción. Esto es necesario para que podamos usarlo awaitdentro de la función.

    Cada tarea pendiente devuelta por la API tiene la siguiente estructura.

    { id: 0, userId: 0, title: 'Some title', completed: true,}

    Queremos devolver una serie de estos cuando

    import { todos } from "./makeTodos"

    La única condición es que cada uno idsea único.

    Cree un nuevo archivo src/makeTodos.jse ingrese el contenido a continuación. Esta es la fuente de todos que usaremos en nuestras pruebas.

    const makeTodos = (n) = { // returns n number of todo items // default is 15 const num = n || 15; const todos = []; for (let i = 0; i num; i++) { todos.push({ id: i, userId: i, title: `Todo item ${i}`, completed: [true, false][Math.floor(Math.random() * 2)], }); } return todos;};export const todos = makeTodos(200);

    Esta función simplemente genera una lista de ntareas pendientes. La completedlínea se establece eligiendo aleatoriamente entre truey false.

    Se supone que las pruebas unitarias son rápidas. Deberían ejecutarse en unos segundos. ¡Fallar rapido! Esta es una de las razones por las que no es práctico permitir que nuestras pruebas realicen llamadas API reales. Para evitar esto, nos burlamos de llamadas API tan impredecibles. Burlarse simplemente significa reemplazar una función con una versión falsa, lo que nos permite personalizar el comportamiento. En nuestro caso, queremos burlarnos del método get de Axios para devolver lo que queramos. Jest ya proporciona una funcionalidad de burla lista para usar.

    Ahora burlemos de Axios para que devuelva esta lista de tareas pendientes cuando realicemos la llamada a la API en nuestra prueba. Cree un archivo src/__mocks__/axios.jse ingrese el siguiente contenido:

    import { todos } from "../makeTodos";export default { get: jest.fn().mockImplementation((url) = { switch (url) { case "https://jsonplaceholder.typicode.com/todos": return Promise.resolve({ data: todos }); default: throw new Error(`UNMATCHED URL: ${url}`); } }),};

    Cuando comienza la prueba, Jest encuentra automáticamente esta carpeta de simulacros y, en lugar de usar el Axios real de node_modules/nuestras pruebas, usa esta. En este punto, solo nos estamos burlando del getmétodo usando el método mockImplementation de Jest . De manera similar, podemos burlarnos de otros métodos de Axios como ,,, postetc. En este momento , todos están indefinidos y cualquier intento de acceder, por ejemplo, resultaría en un error.patchinterceptorsdefaultsaxios.post

     

    Tenga en cuenta que podemos personalizar qué devolver según la URL que recibe la llamada de Axios. Además, las llamadas de Axios devuelven una promesa que se resuelve con los datos reales que queremos, por lo que devolvemos una promesa con los datos que queremos.

    En este punto, tenemos una prueba aprobada y otra reprobada. Implementemos la lógica del componente.

    Abierto src/TodoList.js, desarrollemos la implementación pieza por pieza. Comience reemplazando el código interno con el siguiente.

    import React from "react";import axios from "axios";import { Link } from "react-router-dom";import "./App.css";import { AppContext } from "./AppContext";export const TodoList = () = { const [loading, setLoading] = React.useState(true); const { appData, appDispatch } = React.useContext(AppContext); React.useEffect(() = { axios.get("https://jsonplaceholder.typicode.com/todos").then((resp) = { const { data } = resp; appDispatch({ type: "LOAD_TODOLIST", todoList: data }); setLoading(false); }); }, [appDispatch, setLoading]); return ( div // next code block goes here /div );};

    Importamos AppContexty desestructuramos appDatay appDispatcha partir del valor de retorno de React.useContext. Luego realizamos la llamada API dentro de un useEffectbloque. Una vez que regresa la llamada API, configuramos la lista de tareas pendientes en estado activando la LOAD_TODOLISTacción. Finalmente, configuramos el estado de carga en falso para revelar nuestras tareas pendientes.

    Ahora ingrese el último fragmento de código.

    {loading ? ( pFetching todos/p) : ( ul {appData.todoList.slice(0, 15).map((item) = { const { id, title } = item; return ( li key={id} Link to={`/item/${id}`} data-testid={id} {title} /Link /li ); })} /ul)}

    Cortamos appData.todoListpara obtener los primeros 15 elementos. Luego los asignamos y representamos cada uno en una Link /etiqueta para que podamos hacer clic en él y ver los detalles. Tenga en cuenta el data-testidatributo de cada enlace. Debe ser una identificación única que nos ayudará a encontrar elementos DOM individuales. En el caso de que tengamos texto similar en la pantalla, nunca deberíamos tener el mismo ID para dos elementos. Veremos cómo usar esto un poco más adelante.

    Mis pruebas ahora pasan. ¿El tuyo pasa? Excelente.

    Ahora incorporemos este componente a nuestro árbol de renderizado. Abre, App.jshagámoslo.

    Primeras cosas. Agregue algunas importaciones.

    import { BrowserRouter, Route } from "react-router-dom";import { TodoList } from "./TodoList";

    Necesitamos BrowserRouternavegación y Routerenderizado de cada componente en cada ubicación de navegación.

    Ahora agregue el siguiente código después del header /elemento.

    div className="App-body" BrowserRouter Route exact path="/" component={TodoList} / /BrowserRouter/div

    Esto simplemente le dice al navegador qu






    Tal vez te puede interesar:

    1. 40 bibliotecas útiles de JavaScript
    2. Bibliotecas prácticas de JavaScript y complementos de jQuery
    3. Bibliotecas de JavaScript útiles y complementos de jQuery: parte 2
    4. Bibliotecas JavaScript útiles y complementos jQuery

    Cómo probar sus aplicaciones React con la biblioteca de pruebas React

    Cómo probar sus aplicaciones React con la biblioteca de pruebas React

    SmashingConf Nueva York 2024 Índice Por qué deberías probar tu código

    programar

    es

    https://pseint.es/static/images/programar-como-probar-sus-aplicaciones-react-con-la-biblioteca-de-pruebas-react-1043-0.jpg

    2024-04-04

     

    Cómo probar sus aplicaciones React con la biblioteca de pruebas React
    Cómo probar sus aplicaciones React con la biblioteca de pruebas React

    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