Cómo probar aplicaciones con React Native Testing Library

Su suite de pruebas de React Native es verde, pero un usuario informa que pulsar ‘Continuar’ no hace nada en un dispositivo real. La prueba del componente encontró el botón, llamó a su manejador y vio la pantalla esperada en un entorno de JavaScript simulado. Nunca verificó la solicitud de permiso nativa, el comportamiento del teclado, la animación, la plataforma API o la pila de navegación real.

Es ese vacío donde las equipos obtienen confianza falsa. La biblioteca de pruebas de React Native Es excelente para probar qué un componente renderiza y cómo responde a la interacción del usuario, pero no es un sustituto de la prueba de dispositivos o la medición de rendimiento. La estrategia confiable es utilizar cada capa para los fallos que puede exponer.

Índice de contenido

• ¿Por qué la prueba de usuario cambia todo?
  • Test the behavior users depend on
  • Conoce qué pruebas aprobadas no demuestran
• Instalación y configuración que realmente funciona
  • Mantén los archivos de configuración explícitos
• Explicación de las API, consultas y afirmaciones básicas
  • Elige la consulta según el tiempo y la intención
  • Preferir afirmaciones específicas sobre capturas de pantalla
• Patrones prácticos para componentes, hooks y navegación
  • Componentes presentacionales
  • Navegación y datos asíncronos
  • Mensajes de módulo nativo
• Depuración de pruebas inestables, CI y verificaciones de rendimiento
  • Hacer fracasos de CI reproducibles
  • Trate el rendimiento como una medición, no una afirmación
• Colocando Todo en Su Lugar y Avanzando
  • Un camino práctico de migración

Por qué el Prueba de Centro de Usuario Cambia Todo

Un error de prueba común comienza antes de que se escriba la prueba. Un desarrollador inspecciona las propiedades de un componente, accede a su estado o compara un gran snapshot porque esos detalles son fáciles de afirmar. La prueba pasa, luego una refactorización cambia la estructura del componente sin cambiar la experiencia, y el conjunto de pruebas falla. Peor, la prueba puede seguir pasando mientras que el comportamiento visible para el usuario está mal porque la afirmación nunca describió lo que el usuario necesita ver.

La Biblioteca de Pruebas de React Native toma el enfoque opuesto. Renderiza el componente, interactúa con él a través de un control visible, luego afirma el resultado que un usuario puede observar. Ese enfoque coincide Ejemplo de usuario del React Native Testing LibraryUn diagrama que ilustra los beneficios de la prueba de centro de usuario, destacando el comportamiento del usuario, la resistencia, la confiabilidad y mejores prácticas.

Test the behavior users depend on

Suppose a login form disables its submit button while a request runs. A brittle test might inspect disabled en un componente de instancia particular o afirmar que una variable de estado cambió. Un test más fuerte presiona el control de acceso 'Iniciar sesión', espera al indicador de carga y verifica que aparece un mensaje de error o la pantalla de destino.

El segundo test no se preocupa por si el formulario utiliza el estado local, un reducir, un hook personalizado o una implementación de botón diferente. Se preocupa por si la aplicación comunica el resultado correcto.

Regla práctica: Si un usuario no puede observarlo, cuestione si pertenece a un test de comportamiento de componente.

Las consultas basadas en etiquetas de accesibilidad y roles también fuerzan una mejor experiencia de producto code. Una pantalla que expone etiquetas significativas es más fácil de usar con tecnología asistiva y más fácil de ejercer en pruebas. Esa conexión importa cuando se evalúa la experiencia del usuario más amplia. experiencia del usuario de la aplicación, porque la testabilidad y la usabilidad mejoran a menudo juntas.

Conoce qué pruebas que pasan no demuestran

Un test de componente centrado en el usuario puede demostrar que JavaScript renderiza la rama esperada y responde a un toque simulado. No puede demostrar que una solicitud de biometría se abre correctamente, que una cámara nativa devuelve un resultado usable o que un flujo de pago resiste el comportamiento de ciclo de vida específico de la plataforma.

Esos límites no son una debilidad de la biblioteca. Es una razón para mantener honestos los capas de test. Utilice RNTL para el comportamiento de componente, luego reserve los tests de dispositivo para los flujos donde la integración nativa, la navegación real, los permisos, la autenticación, los pagos o la funcionalidad de aplicación principal pueden cambiar el resultado.

Instalación y configuración que realmente funciona

La configuración moderna comienza con el paquete de ámbito:

@testing-library/react-native

El más antiguo react-native-testing-library El nombre del paquete npm todavía existe como un artefacto histórico, pero los proyectos actuales deben utilizar el paquete de ámbito mantenido dentro de la familia de Testing Library. El repositorio del proyecto npm repositorio de GitHub Instale la biblioteca con su entorno Jest existente. Los proyectos de Expo comúnmente utilizan el preset de Jest de Expo, mientras que los proyectos de React Native desnudos pueden utilizar el preset de React Native:

Install the library with your existing Jest environment. Expo projects commonly use the Expo Jest preset, while bare React Native projects may use the React Native preset:

npm install --save-dev @testing-library/react-native jest

Para Expo, agrega el preset que ya está utilizando tu proyecto:

{
  "scripts": {
    "test": "jest"
  },
  "jest": {
    "preset": "jest-expo"
  }
}

For a bare React Native application, use the corresponding React Native Jest configuration instead. Keep the preset aligned with the framework version. Many failures that look like RNTL problems come from a mismatched React renderer, Babel transform, or Jest preset.

Mantén archivos de configuración explícitos

Configura la configuración del entorno compartido en un archivo de configuración en lugar de repetir los mocks en cada prueba.

// jest.setup.js
import '@testing-library/react-native/extend-expect';

Entonces, referencia desde Jest:

{
  "jest": {
    "preset": "jest-expo",
    "setupFilesAfterEnv": ["<rootDir>/jest.setup.js"]
  }
}

Si su aplicación utiliza React Navigation, Reanimated, manejo de gestos, contexto de área segura o módulos de almacenamiento, configure solo las simulaciones que necesita su entorno de prueba. Una simulación global que cambia el comportamiento de la aplicación puede hacer que cada prueba sea más fácil de aprobar, aunque esto hace que el conjunto de pruebas sea menos confiable.

TypeScript necesita la misma atención. Asegúrese de que Jest transforme .ts y .tsx los archivos a través del preset o su configuración de Babel, y mantenga disponibles los tipos de prueba para el compilador. Una prueba que se ejecuta localmente pero no se verifica por tipo puede ocultar nombres de consultas incorrectos, parámetros de navegación inválidos o formas de simulación inseguras.

La cronología de lanzamientos es útil al diagnosticar consejos de configuración más antiguos. La lista del proyecto 127 lanzamientos, con v14.0.1 etiquetado en 2026-06-23, mientras que v12.9.0, lanzado en 2024-11-27, agregó el soporte oficial para React Native 0.77 y Expo 52.El línea de alpha v14 en marzo de 2025 se movió a Universal Test Renderer desde el React Test Renderer deprecated y se preparó para el soporte de React 19 solo. Estos detalles aparecen en la historia de lanzamientos de RNTLNo copies una dependencia de renderizador de una tutoría desactualizada sin verificar las versiones de tu aplicación.

Para una base práctica de Jest, compare su configuración con esta Guía de pruebas unitarias de Jest, luego ejecute una prueba de componente pequeña antes de agregar navegación y mocks nativos.

Explicación de las API, consultas y afirmaciones centrales

Las pruebas de RNTL se vuelven confiables cuando sus consultas coinciden con lo que un usuario puede ver, encontrar y operar. El API es pequeño, pero elegir un selector que expone detalles de implementación puede hacer que una prueba que pasa sea engañosa.

Comience con render:

const screen = render(<LoginForm />);

Elige la consulta más relevante para el usuario disponible. Prefiere consultas orientadas a la accesibilidad cuando el componente las expone, utiliza texto visible cuando el texto es el comportamiento y reserva testID para casos sin un selector significativo para el usuario o donde se necesita una conexión de integración estable.

Elige la consulta por tiempo y intención

Cada familia de consultas tiene un propósito distinto:

• Presencia sincrónica: Usar getByRole, getByText, or another getBy consulta cuando el elemento ya debe existir. La prueba falla inmediatamente si no lo hace.
• Aplicación asincrónica: Usar findByRole o findByText cuando la renderización o la interacción causan una actualización asíncrona.
• Verificaciones de ausencia: Usar queryByText o queryByTestId cuando un elemento puede estar faltando y se espera un resultado nulo en lugar de una excepción.
• Selectores de fallback: Usar getByTestId intencionalmente. Proporciona a los controles complejos una conexión duradera, pero no debe reemplazar los etiquetas accesibles en toda la aplicación.

Para pruebas de eventos enfocados, fireEvent.press es directo:

fireEvent.press(screen.getByRole('button', { name: 'Save' }));

Usar userEvent cuando la versión instalada admite la secuencia de interacción más realista. De cualquier manera, aser el resultado UI:

expect(await screen.findByText('Saved')).toBeTruthy();

Una afirmación de manejador se ajusta a un componente cuyo contrato público es una llamada a eventos. Es débil como única evidencia de que el recorrido del usuario funciona.

Preferir afirmaciones específicas sobre capturas de pantalla

Las afirmaciones buenas describen la pantalla:

expect(screen.getByText('Account created')).toBeTruthy();
expect(screen.getByRole('button', { name: 'Continue' })).toBeEnabled();

Pueden verificar también el estado de accesibilidad, selección y retroalimentación de validación visible. Eviten verificar la configuración interna.

expect(screen.getByTestId('submit-button').props.onPress).toBeDefined();

La afirmación demuestra que existe una propiedad, no que el feature funciona. Las capturas de pantalla pequeñas e intencionales pueden capturar cambios estructurales, mientras que las capturas de pantalla grandes de navegación o pantalla a menudo crean revisiones ruidosas y hacen que las actualizaciones no explicadas sean fáciles de aprobar.

El paquete de Testing Library pertenece a la organización más amplia testing-library La organización npm. Sus paquetes activos incluyen @testing-library/react-nativecon la versión 13.3.3 publicado en 2026según la información del repositorio del proyecto información del repositorioConvenios de consultas compartidas ayudan en varias plataformas, pero no determinan qué aserción representa el comportamiento de tu producto.

Para una comparación más amplia de las prácticas de pruebas de componentes de Jest, consulte esta guía pruebas unitarias de React. RNTL still stops at the JavaScript-rendered component boundary. Native permissions, real navigation stacks, device keyboards, frame timing, and memory behavior need E2E or performance tooling rather than more component mocks.

El video a continuación demuestra el flujo de consulta y afirmación en contexto.

Patrones Prácticos para Componentes, Hooks y Navegación

Una suite de pruebas útil sigue la forma de la aplicación. Los componentes presentacionales necesitan pruebas de comportamiento directo, los hooks necesitan entradas y salidas controladas, la navegación necesita un proveedor lo suficientemente realista y los módulos nativos necesitan mocks que permanezcan visiblemente diferentes de la verificación de dispositivo real.

Componentes presentacionales

Mantén una prueba de componente cerca de su contrato público:

const onSelect = jest.fn();

render(
  <PlanCard
    title="Team"
    description="Shared workspace"
    onSelect={onSelect}
  />
);

fireEvent.press(screen.getByRole('button', { name: 'Choose Team' }));

expect(onSelect).toHaveBeenCalled();

El etiqueta exacta debe coincidir con su interfaz de usuario. La parte importante es que la prueba encuentre el control de la manera en que lo haría un usuario o un servicio de accesibilidad y confirme el resultado visible o de llamada que importa. No mocke por defecto cada componente hijo. Mocke solo las fronteras costosas o no relacionadas cuando obscurezcan el comportamiento que se está probando.

Para un hook personalizado, utilice renderHook cuando la versión instalada de RNTL lo proporciona:

const { result } = renderHook(() => useSearch());

await act(async () => {
  await result.current.submit('query');
});

expect(result.current.status).toBe('success');

La prueba del hook debe controlar la frontera de red o de repositorio, no reproducir toda la aplicación. Prueba la pantalla por separado para saber si el estado del hook se vuelve útil en la interfaz de usuario.

Navegación y datos asíncronos

Para el comportamiento de navegación, renderizar una pantalla dentro de un real NavigationContainer y un navegador de prueba pequeño es a menudo más valioso que mockear cada método de navegación. Presione un control visible, espere al contenido de destino y aserte el nuevo contenido de pantalla. Una prueba directa useNavigation mock sigue siendo apropiado para un pequeño botón cuya única responsabilidad es enviar una ruta tipada, pero no validará la registro de rutas, parámetros o comportamiento de navegador anidado.

Los datos asíncronos merecen la misma disciplina. Simule la API o respuesta del repositorio, renderice la pantalla, asuma el estado de carga, resuelva la solicitud, luego asuma el éxito o el error de salida. Utilice findBy consultas para elementos esperados eventualmente y haga solicitudes rechazadas explícitas, de lo contrario, una prueba puede pasar porque el componente nunca alcanzó el ramal deseado.

Mocks de módulos nativos

Los mocks para AsyncStorage, permisos, cámaras, biometrías y APIs de plataforma son útiles para pruebas de JavaScript determinísticas. No son evidencia de que la característica nativa funcione. Mantenga el comportamiento del mock cerca del contrato del módulo, reinicie las llamadas entre pruebas y incluya respuestas de error en lugar de modelar solo el camino feliz.

La frontera es práctica: simule la dependencia para probar sus decisiones de JavaScript, luego ejecute un test de dispositivo para confirmar el comportamiento real de la dependencia.

Depuración de Pruebas Inestables Verificación de Rendimiento y CI

Una prueba inestable suele indicar un tiempo no controlado, un estado compartido o una afirmación que compite con la interfaz de usuario. Identifique la condición presente antes de aumentar los tiempos de espera. Un tiempo de espera más largo puede ocultar el problema de programación y hacer que el conjunto de pruebas sea más lento.

Usar findBy para elementos esperados después de una actualización. Usar waitFor para condiciones de estado o llamadas de mock. Si se habilitan temporizadores falsos, avance a ellos en el punto en que se requiere la interacción y restaura los temporizadores reales después. Un act Advertencia significa que React observó una actualización fuera de su límite de interacción esperado. Corrija la falta de await, la supresión de advertencias en lugar de suprimirlas.

Hacer fracasos de CI reproducibles

A dependable CI job installs from the lockfile, runs the same Jest command used locally, and isolates mock state. Clear mock calls between tests, reset modules when module-level state affects behavior, and remove dependencies on execution order. Jest caching speeds feedback, but dependency or configuration changes require appropriate cache invalidation.

Las fallas solo de CI necesitan una comparación de entorno antes de una reescritura de componente. Verifique Node, el administrador de paquetes, las configuraciones de trabajadores de Jest, la configuración de temporizador y las variables de entorno. Reproduzca el mismo comando localmente donde sea posible, luego reduzca la prueba fallida a la interacción más pequeña que expone la diferencia.

La observabilidad cubre una brecha diferente. Una herramienta como Sentry para React Native fornecen producción error contexto que las pruebas de componentes simulados no pueden reproducir, incluyendo fallas vinculadas a dispositivos reales y integraciones nativas.

Security-sensitive journeys need a second boundary. Use component tests for validation and state transitions, then add device-level coverage for the handoff and native behavior. For one-time-code flows, consult guidance on how to probar flujos de verificación de SMS cuando esa integración forma parte del viaje.

Trate el rendimiento como medida, no como afirmación

Una prueba funcional puede confirmar que una lista se renderiza. No puede determinar con fiabilidad si un refactor cambió la duración de la renderización o el recuento de renderizaciones, porque el tiempo de ejecución de la prueba agrega ruido. Reafirme los valores de medida para un escenario, repita el escenario para reducir la variabilidad y aplique el análisis estadístico antes de informar un cambio significativo. Su documentación de pruebas de rendimiento también cubre informes adecuados para la CI y la revisión de solicitudes de extracción.

Evite afirmaciones fijas como “esta renderización debe terminar debajo de un umbral elegido.” Un trabajador de CI ocupado puede desencadenar una falsa falla, mientras que un umbral suelto puede pasar por alto una regresión real. Utilice mediciones repetidas para señales de regresión, luego inspeccione el componente y el perfil de dispositivo cuando la comparación muestre una diferencia significativa.

Regla de medición: Pruebas funcionales responden si el comportamiento es correcto. Las herramientas de rendimiento responden si un escenario medido cambió. Mantenga esas preguntas separadas.

Colocando Todo en Su Lugar y Avanzando

La Biblioteca de Pruebas de React Native pertenece a la capa rápida y amplia de su estrategia de pruebas. Debe cubrir el comportamiento de los componentes, los cambios de estado visibles, los resultados de accesibilidad, la validación, los estados de datos simulados y la integración entre componentes de JavaScript. Mantenga esas pruebas enfocadas en lo que un usuario puede observar, y haga que las fallas apunten a un comportamiento específico en lugar de un gran árbol renderizado.

La capa de dispositivo más pequeño debe proteger los flujos donde los mocks pueden estar. Resumen de pruebas states that RNTL doesn’t provide a full React Native runtime and can’t test native features. The same guidance recommends pairing component tests with E2E tools such as Detox for critical flows including authentication, payments, and core app functionality.

Un camino de migración práctico

No necesita reescribir un conjunto existente en una sola pasada.

1. Mantén pruebas comerciales valiosas. Mueva el estado puro y la lógica de dominio a pruebas unitarias enfocadas donde proporcionan feedback claro.
2. Sustituye las afirmaciones de implementación primero. Convierte las comprobaciones de propiedades y estado interno en salida visible, estado de accesibilidad y resultados de interacción.
3. Reduce las capturas de pantalla. Considere solo capturas de pantalla que los revisores puedan comprender y mantener.
4. Agrega cobertura de límites nativos. Para cada módulo mockeado importante, identifica el comportamiento del dispositivo que aún necesita validación.
5. Protégete los viajes críticos. Agregar cobertura E2E para autenticación, pago, navegación principal, permisos y otros flujos donde el comportamiento nativo puede cambiar el resultado.
6. Medir pantallas sensibles por separado. Utiliza comparaciones de rendimiento repetidas para listas, feeds y rutas de renderizado costosas en lugar de suponer desde la duración de Jest.

Para la confianza de lanzamiento, conecta el conjunto a la integración de prueba de CI/CD y requiere la capa de prueba adecuada antes de enviar. Si una corrección de JavaScript o activo debe llegar a los usuarios después de la validación, Capgo puede entregar paquetes web firmados a los canales objetivo para aplicaciones de CapacitorJS y Electron, con controles de lanzamiento y protección de rollback. Ese flujo de entrega no reemplaza las pruebas de dispositivos de React Native, pero ilustra el mismo principio: validar el comportamiento en la capa donde se ejecuta.

No es la pregunta correcta si React Native Testing Library puede probar toda tu aplicación. No puede, y la frontera oficial es útil. La pregunta correcta es si cada riesgo importante tiene una prueba ejecutándose en el entorno capaz de exponerlo.

Capgo conecta cambios de JavaScript y activos validados a la entrega controlada para equipos de CapacitorJS y Electron, con canales objetivo, visibilidad de lanzamiento y protección de rollback. Visite Capgo para ver cómo puede encajar junto con tu componente, E2E y CI de pruebas.