¿Cómo probar aplicaciones con React Native Testing Library?

Tu suite de pruebas de React Native está 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 manipulador 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 allí donde los equipos obtienen confianza falsa. React Native Testing Library es excelente para probar qué un componente renderiza y cómo responde a la interacción del usuario, pero no es un sustituto para la prueba de dispositivos o la medición de rendimiento. La estrategia confiable es utilizar cada capa para los fallos que puede exponer.

Contenido de la Tabla

• Por qué la Prueba Centrada en el Usuario Cambia Todo
  • Prueba el comportamiento en el que los usuarios confían
  • Sabe qué pruebas que pasan no demuestran
• Instalación y Configuración que Funciona Realmente
  • Mantén los archivos de configuración explícitos
• Explicación de las API, Consultas y Declaraciones de Verdad
  • Elige la consulta según el tiempo y la intención
  • Preferir declaraciones de verdad específicas sobre capturas de pantalla
• Patrones Prácticos para Componentes, Hooks y Navegación
  • Componentes presentacionales
  • navegación y datos asíncronos
  • mockeos de módulos nativos
• Depuración de pruebas inestables, verificación de rendimiento y comprobación de CI
  • Hacer reproducibles las fallas de CI
  • Tratar el rendimiento como una medida, no como una afirmación
• Colocar todo en su lugar y avanzar
  • Un camino de migración práctico

Por qué el testing centrado en el usuario cambia todo

Una común falla de prueba 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 un refactor 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 El ejemplo de la biblioteca de pruebas de React Native centrado en el usuarioAdemás de la guía de pruebas de React Native, para mantener las pruebas cortas, centrar cada prueba en una cosa, separar las preocupaciones de la vista de la lógica de negocio y el estado, y preferir la salida visible o los ayudantes de accesibilidad sobre los detalles de implementación interna.

Prueba el comportamiento en el que los usuarios confían

Supongamos que un formulario de inicio de sesión deshabilita su botón de envío mientras se ejecuta una solicitud. Una prueba frágil podría inspeccionar disabled en una instancia de componente particular o afirmar que una variable de estado cambió. Una prueba 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.

La segunda prueba 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 de que la aplicación comunique el resultado correcto.

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

Las consultas basadas en etiquetas de accesibilidad y roles también fuerzan mejores productos 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 del aplicativoporque la testabilidad y la usabilidad mejoran a menudo juntas.

Conoce qué pruebas que pasan no demuestran

A un componente centrado en el usuario, una prueba puede demostrar que JavaScript renderiza la rama esperada y responde a un toque simulado. Sin embargo, no puede probar que una solicitud de identificación biométrica 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.

Esta frontera no es una debilidad de la biblioteca. Es una razón para mantener honestos los niveles de prueba. Utilice RNTL para el comportamiento de componentes, y reserve las pruebas basadas en dispositivos para flujos donde la integración nativa, la navegación real, los permisos, la autenticación, los pagos o la funcionalidad de la aplicación principal pueden cambiar el resultado.

Instalación y Configuración que Funciona Realmente

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

@testing-library/react-native

El paquete de ámbito más antiguo todavía existe como un artefacto histórico, pero los proyectos actuales deben utilizar el paquete de ámbito mantenido dentro de la familia de la Biblioteca de Pruebas. El repositorio del proyecto react-native-testing-library npm package name still exists as a historical artifact, but current projects should use the scoped package maintained within the Testing Library family. The project’s GitHub repository Para Expo, agregue el preset que su proyecto ya utiliza:

El paquete de ámbito más antiguo todavía existe como un artefacto histórico, pero los proyectos actuales deben utilizar el paquete de ámbito mantenido dentro de la familia de la Biblioteca de Pruebas.

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

Describe las utilidades de React Native para fomentar buenas prácticas de prueba, y su historia de liberación muestra que la biblioteca ha seguido cambiando junto con React Native en lugar de permanecer como un ayudante estático.

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

Para una aplicación React Native básica, utilice la configuración de Jest de React Native correspondiente. Mantenga el preset alineado con la versión del marco de trabajo. Muchas fallas que parecen problemas de RNTL provienen de una configuración de renderizador de React, transformación de Babel o preset de Jest desalineada.

Mantenga los archivos de configuración explícitos

Coloque 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';

Luego, hágala 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 los mocks que necesita su entorno de prueba. Un mock global que cambia el comportamiento de la aplicación puede hacer que cada prueba sea más fácil de pasar, pero 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 los tipos de prueba disponibles para el compilador. Una prueba que se ejecuta localmente pero no se verifica de tipo puede ocultar nombres de consultas incorrectos, parámetros de navegación inválidos o formas de mock inseguras.

La cronología de lanzamientos es útil cuando se diagnostican consejos de configuración más antiguos. El proyecto lista 127 lanzamientos, con v14.0.1 etiquetado en 2026-06-23mientras que v12.9.0, lanzado el 27 de noviembre de 2024, agregó el soporte oficial para React Native 0.77 y Expo 52. La línea de v14 alpha 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 lahistoria de lanzamientos de RNTL

, por lo tanto, no copie una dependencia de renderizador de una tutoría obsoleta sin verificar las versiones de su aplicación Para una base práctica de Jest, compare su configuración contra esteguía de pruebas unitarias de Jest

Un gráfico infográfico que muestra el camino de cinco pasos para configurar el proyecto de la biblioteca de pruebas de React Native

RNTL tests become trustworthy when their queries match what a user can see, find, and operate. The API is small, but choosing a selector that exposes implementation details can make a passing test misleading.

Las pruebas de RNTL se vuelven confiables cuando sus consultas coinciden con lo que un usuario puede ver, encontrar y operar. El __CAPGO_KEEP_0__ es pequeño, pero elegir un selector que expone detalles de implementación puede hacer que una prueba que pasa sea engañosa 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 integración estable de hook.

Elige la consulta según el tiempo y la intención

Cada familia de consultas tiene un propósito distinto:

• Presencia sincrónica: Utiliza getByRole, getByTexto otra getBy consulta cuando el elemento ya debe existir. La prueba falla inmediatamente si no lo hace.
• Aplicación asincrónica: Utiliza findByRole o findByText When se produce una actualización asíncrona al renderizar o interactuar.
• Verificaciones de ausencia: Usar queryByText o queryByTestId ¿Cuándo elegir entre Capawesome, Appflow o la actualización en vivo de Capacitor?
• ¿Cuándo elegir entre Appflow o los plugins de Ionic Enterprise? ¿Cuándo elegir entre Capawesome o Appflow? getByTestId ¿Cuándo elegir entre la actualización en vivo de Capacitor o los plugins de Ionic Enterprise?

¿Cuándo elegir entre Appflow o la actualización en vivo de Capacitor? fireEvent.press ¿Cuándo elegir entre Capawesome o la actualización en vivo de Capacitor?

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

¿Cuándo elegir entre Appflow o Capawesome? userEvent ¿Cuándo elegir entre la actualización en vivo de Capacitor o Capawesome?

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

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

Preferir afirmaciones específicas sobre capturas de pantalla

Las buenas afirmaciones describen la pantalla:

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

Además, pueden verificar el estado de accesibilidad, la selección y la retroalimentación de validación visible. Evite verificar la cableado interno:

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

Esta afirmación prueba que existe una propiedad, no que el característica funcione. Las capturas de pantalla pequeñas e intencionales pueden capturar cambios estructurales, mientras que las capturas de pantalla de navegación grandes o de pantalla a menudo crean revisiones ruidosas y hacen que las actualizaciones inexplicables sean fáciles de aprobar.

El paquete de Testing Library pertenece a la organización más amplia testing-library npm @testing-library/react-nativeSu paquetes activos incluyen , con versión13.3.3 publicado en 2026 , según la información del repositorio del proyecto. Las convenciones de consultas compartidas ayudan a través de plataformas, pero no deciden qué afirmación representa el comportamiento de su producto.

Para una comparación más amplia de las prácticas de pruebas de componentes de Jest, consulte esta guía sobre pruebas unitarias de React. RNTL todavía se detiene en la frontera del componente renderizado en JavaScript. Las permisos nativos, las pilas de navegación reales, los teclados de dispositivos, el tiempo de marco y el comportamiento de memoria necesitan herramientas de pruebas E2E o de rendimiento en lugar de más mocks de componentes.

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

Patrones prácticos para componentes, hooks y navegación

Un conjunto 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 sean 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 mocks por defecto cada componente hijo. Mocke las fronteras caras o no relacionadas solo cuando obscurezcan el comportamiento bajo prueba.

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');

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

Navegación y datos asíncronos

Para el comportamiento de navegación, renderizar una pantalla dentro de una navegación 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 asuma el nuevo contenido de pantalla. Un mock directo todavía es apropiado para un pequeño botón cuya única responsabilidad es enviar una ruta de tipo, pero no validará la registro de rutas, parámetros o comportamiento de navegador anidado. useNavigation Los datos asíncronos merecen el mismo rigor. Mocke la respuesta del repositorio o __CAPGO_KEEP_0__, renderice la pantalla, asuma el estado de carga, resuelva la solicitud, luego asuma el éxito o el error de salida. Utilice 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.

Async data deserves the same discipline. Mock the API or repository response, render the screen, assert the loading state, resolve the request, then assert success or error output. Use findBy 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 funciona. Mantenga el comportamiento del mock cerca del contrato del módulo, reinicie las llamadas entre pruebas y incluya respuestas de falla en lugar de modelar solo el camino feliz.

Escenario

Mejor con RNTL

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.

Comprobación de pruebas inestables, comprobaciones de rendimiento y CI

Una prueba inestable suele apuntar a un tiempo no controlado, un estado compartido o una afirmación que compite con la interfaz de usuario. Identifique qué condición está 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 que aparecen después de una actualización. Usar waitFor para condiciones de estado o llamadas de simulación. Si se habilitan los temporizadores falsos, avance a ellos en el punto en que se requiere la interacción y restaure los temporizadores reales después. act warning significa que React observó una actualización fuera de su frontera de interacción esperada. Corrija la falta de awaitinteracción del usuario o la descarga del temporizador en lugar de suprimir la advertencia.

Haga que las fallas de CI sean reproducibles

Un trabajo CI confiable instala desde el archivo de bloqueo, ejecuta el mismo comando de Jest utilizado localmente y aísla el estado de las pruebas de mock. Limpie las llamadas de mock entre pruebas, reinicie los módulos cuando el estado de módulo afecte el comportamiento y elimine las dependencias del orden de ejecución. La caché de Jest acelera la retroalimentación, pero los cambios en dependencias o configuración requieren una invalidación de caché adecuada.

Las fallas de CI solo necesitan una comparación de entorno antes de una reescritura de componentes. Verifique Node, el administrador de paquetes, las configuraciones de trabajadores de Jest, la configuración de temporizadores 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 proporciona contexto de errores de producción que las pruebas de componentes mockeadas no pueden reproducir, incluidas las fallas relacionadas con 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 una medición, no como una afirmación

A un test funcional puede confirmar que una lista se renderiza. No puede determinar con certeza si un refactor cambió la duración de la renderización o el recuento de renderizaciones, porque el tiempo de ejecución del test agrega ruido. Revisa los valores de medición para un escenario, repite el escenario para reducir la variabilidad y aplica análisis estadístico antes de informar un cambio significativo. También documentación de pruebas de rendimiento también cubre informes adecuados para la revisión de CI y solicitudes de extracción.

Evite afirmaciones fijas como “esta renderización debe terminar por 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: Los tests funcionales responden si el comportamiento es correcto. Las herramientas de rendimiento responden si un escenario medido cambió. Mantenga esas preguntas separadas.

Colocar todo en su lugar y avanzar

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 esos tests enfocados 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 más pequeña basada en dispositivos debe proteger los flujos donde los mocks pueden estar presentes. La visión general de pruebas de React Native es una página que describe cómo realizar pruebas en React Native. afirma que RNTL no proporciona un tiempo de ejecución React Nativo completo y no puede probar características nativas. La misma guía recomienda combinar pruebas de componentes con herramientas E2E como Detox para flujos críticos que incluyen autenticación, pagos y funcionalidad de aplicación principal.

Un camino de migración práctico

No necesita reescribir un conjunto existente en una sola pasada.

1. Conservar pruebas comerciales valiosas. Desplazar la lógica de estado y de dominio pura a pruebas unitarias enfocadas donde proporcionan retroalimentación clara.
2. Sustituir primero las afirmaciones de implementación. Cambiar las comprobaciones de propiedades y estado interno en salida visible, estado de accesibilidad y resultados de interacción.
3. Reducir capturas de pantalla. Retener solo capturas de pantalla que los revisores puedan comprender y mantener.
4. Agregar cobertura de fronteras nativas. Para cada módulo mockeado importante, identifique el comportamiento del dispositivo que todavía necesita validación.
5. Proteger viajes críticos. Agregar cobertura E2E para la autenticación, pago, navegación principal, permisos y otros flujos donde el comportamiento nativo puede cambiar el resultado.
6. Medir pantallas sensibles por separado. Usar comparaciones de rendimiento repetidas para listas, feeds y rutas de renderizado costosas en lugar de adivinar desde la duración de Jest.

Para la confianza de la versión, conectar el conjunto a integración de pruebas de CI/CD y requerir 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.

La pregunta correcta no es si la biblioteca de pruebas de React Native puede probar toda la 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 su componente, E2E, y flujo de pruebas de CI.