Su suite de pruebas de React Native está verde, pero un usuario aún 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.
La brecha es donde los equipos obtienen confianza falsa. 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 para la prueba de dispositivos o la medición de rendimiento. La estrategia confiable es usar cada capa para los fallos que puede exponer.
Contenido de la Tabla
- ¿Por qué la Prueba Centrada en el Usuario Cambia Todo
- Instalación y Configuración que Funciona Realmente
- APIs de Núcleo Consultas y Afirmaciones Explicadas
- Patrones prácticos para componentes, hooks y navegación
- Depuración de pruebas inestables, verificaciones de CI y rendimiento
- Colocando Todo en Acción y Avanzando
¿Por qué la Prueba de Centro del Usuario Cambia Todo
A un error común de prueba comienza antes de que se escriba la prueba. Un desarrollador inspecciona las propiedades de un componente, accede a su estado o compara una gran instantánea 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 se rompe. Peor, la prueba puede seguir pasando mientras que el comportamiento visible para el usuario está mal porque la afirmación nunca describió qué 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 con Ejemplo de usuario del React Native Testing LibraryUna ilustración que destaca los beneficios de la prueba centrada en el usuario, resaltando 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 on a particular component instance or assert that a state variable changed. A stronger test presses the accessible “Sign in” control, waits for the loading indicator, and checks that an error message or the destination screen appears.
El segundo test no se preocupa por si el formulario utiliza un 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 un comportamiento de prueba de componente.
Las consultas basadas en etiquetas de accesibilidad y roles también obligan a una mejor 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ónporque la testabilidad y la usabilidad mejoran a menudo juntas.
Conoce qué pruebas que pasan no demuestran
Una prueba de componente centrada en el usuario puede demostrar que JavaScript renderiza la rama esperada y responde a un toque simulado. No puede demostrar 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 sobrevive al comportamiento del ciclo de vida específico de la plataforma.
Que límite no es una debilidad de la biblioteca. Es una razón para mantener honestos los capas de prueba. Utilice RNTL para el comportamiento de componente, luego reserve las pruebas 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 la aplicación principal pueden cambiar el resultado.
Instalación y Configuración que Funciona Realmente
La configuración moderna comienza con el paquete escalado:
@testing-library/react-nativeEl más antiguo react-native-testing-library El nombre de paquete npm todavía existe como un artefacto histórico, pero los proyectos actuales deben utilizar el paquete escalado mantenido dentro de la familia de Testing Library. El proyecto’s El repositorio GitHub lo describe como utilidades de React Native para fomentar buenas prácticas de prueba, y su historia de lanzamiento muestra que la biblioteca ha seguido cambiando junto con React Native en lugar de permanecer como un ayudante estático.
Instale la biblioteca con su entorno Jest existente. Los proyectos de Expo suelen utilizar el preset de Jest de Expo, mientras que los proyectos de React Native desnudos pueden utilizar la configuración de Jest de React Native:
npm install --save-dev @testing-library/react-native jestPara Expo, agregue el preset que su proyecto ya utiliza:
{
"scripts": {
"test": "jest"
},
"jest": {
"preset": "jest-expo"
}
}Para una aplicación de React Native desnuda, utilice la configuración de Jest correspondiente de React Native. Mantenga el preset alineado con la versión del marco. Muchos errores que parecen ser problemas de RNTL provienen de una configuración de React renderer, transformación de Babel o preset de Jest desalineada.
Mantenga los archivos de configuración explícitos
Coloque la configuración del entorno compartida 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';Y luego referencie 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 (Y) .tsx archivos a través de la configuración predeterminada o de tu configuración de Babel, y mantén disponibles los tipos de prueba 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 la versión es útil al diagnosticar consejos de configuración más antiguos. La lista del proyecto 127 versiones, 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. La 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 versiones de RNTLNo copie una dependencia de renderizador de una tutoría desactualizada sin verificar las versiones de su aplicación.
Para una base de Jest práctica, compara tu configuración contra este guía de pruebas unitarias de JestEntonces, ejecuta una prueba de un componente pequeño antes de agregar navegación y mocks nativos.
Explicación de las API, consultas y afirmaciones centrales.
Las pruebas de RNTL se vuelven fiables 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.
Comienza con render:
const screen = render(<LoginForm />);Elija la consulta más relevante para el usuario disponible. Prefiera consultas orientadas a la accesibilidad cuando el componente las expone, utilice texto visible cuando el texto es el comportamiento, y reserve testID para casos sin un selector significativo para el usuario o donde se necesita una integración estable.
Elige la consulta por tiempo y intención
Cada familia de consultas tiene un propósito distinto:
- Presencia sincrónica: Usa
getByRole,getByText, or anothergetByquery when the element should already exist. The test fails immediately if it does not. - Presencia asincrónica: Usar
findByRoleofindByTextcuando la aparición o la interacción causa una actualización asíncrona. - Verificaciones de ausencia: Usar
queryByTextoqueryByTestIdcuando un elemento puede estar ausente y se espera un resultado nulo en lugar de una excepción. - Selectores de reemplazo: Usar
getByTestIdintencionalmente. Proporciona un gancho duradero a controles complejos, pero no debe sustituir 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, aserte el resultado de la interfaz:
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();También pueden verificar el estado de accesibilidad, selección y retroalimentación de validación visible. Evite verificar la conexión interna:
expect(screen.getByTestId('submit-button').props.onPress).toBeDefined();Esta afirmación prueba que existe una propiedad, no que el caracter 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 no explicadas sean fáciles de aprobar.
La paquete de Testing Library pertenece a la amplia testing-library 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 repositorioLas convenciones de consultas compartidas ayudan en varias plataformas, pero no deciden qué afirmación representa el comportamiento de tu producto.
Para una comparación más amplia de las prácticas de prueba de componentes de Jest, consulte esta guía pruebas unitarias de React. RNTL todavía se detiene en la frontera del componente JavaScript-renderizado. 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 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.
Hábitos 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 directas, 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 un test 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 el test encuentre el control de la manera que lo haría un usuario o un servicio de accesibilidad y confirme el resultado visible o de llamada de retorno que importa. No mocke cada componente hijo por defecto. Mocke las fronteras costosas o no relacionadas solo cuando obstruyan 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');El test del hook debe controlar la frontera de red o de repositorio, no reproducir la aplicación completa. Pruebe la pantalla por separado para saber si el estado del hook se convierte en una interfaz útil.
La navegación y los datos asíncronos
Para el comportamiento de navegación, renderizar una pantalla dentro de una NavigationContainer and a small test navigator is often more valuable than mocking every navigation method. Press a visible control, wait for the destination content, and assert the new screen’s output. A direct useNavigation mock is still appropriate for a small button whose only responsibility is dispatching a typed route, but it won’t validate route registration, parameters, or nested navigator behavior.
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 Las consultas para elementos esperados eventualmente y hagan explícitas las solicitudes rechazadas, de lo contrario, una prueba puede pasar porque el componente nunca alcanzó el ramo previsto.
Modulos nativos simulados
Los mocks para AsyncStorage, permisos, cámaras, biometría y APIs de plataforma son útiles para pruebas de JavaScript determinísticas. No son evidencia de que el característica nativa funciona. Mantenga el comportamiento del mock cerca del contrato del modulo, reinicie las llamadas entre pruebas y incluya respuestas de falla en lugar de modelar solo el camino feliz.
| Escenario | Mejor con RNTL | Requiere validación E2E |
|---|---|---|
| Validación de formulario y errores visibles | Sí | Normalmente |
| Carga, éxito y errores de UI desde un repositorio simulado | Sí | Para flujo de producción crítico |
| Navegación entre pantallas registradas | Sí, con un navegador de pruebas | Sí cuando importan gestos, enlaces profundos o el comportamiento de la plataforma. |
| Decisiones de estado de AsyncStorage | Sí, con un mock controlado | Sí, cuando se lanzan y persisten la interacción con el ciclo de vida nativo. |
| Cámara, biometría, permisos o APIs de plataforma | Retroceso de JS y lógica de ramificación | Sí, en dispositivos reales o representativos |
| Diseño, rendimiento de renderizado y nativo code | No | Sí, con herramientas de dispositivo o especializadas |
La frontera es práctica: simule la dependencia para probar sus decisiones de JavaScript, luego realice un test de dispositivo para confirmar el comportamiento real de la dependencia.
Depuración de Pruebas Inestables CI y Verificaciones de Rendimiento
Una prueba inestable a menudo apunta a 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 que aparecen después de una actualización. Usar waitFor para condiciones de estado o llamadas de mock. Si los temporizadores falsos están habilitados, 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 frontera de interacción esperada. Corrija el missing awaitinteracción del usuario o el flujo de temporizadores en lugar de suprimir la advertencia.
Hacer fracasos de CI reproducibles
Un trabajo de CI confiable instala desde el archivo de bloqueo, ejecuta el mismo comando de Jest utilizado localmente y aísla el estado de mock. Limpie las llamadas de mock entre pruebas, resetea los módulos cuando el estado de módulo afecta el comportamiento y elimine dependencias de la 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 reescribir un componente. Verifique Node, el administrador de paquetes, los ajustes del trabajador de Jest, la configuración de temporizadores y 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 error de producción que los tests de componentes mockeados no pueden reproducir, incluyendo 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 una afirmación
Una prueba funcional puede confirmar que una lista se renderiza. Sin embargo, 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 de la prueba agrega ruido. Asegurese de medir esos valores 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 also covers reporting suitable for CI and pull-request review.
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, y luego inspeccione el componente y el perfil del dispositivo cuando la comparación muestra 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 los errores apunten a un comportamiento específico en lugar de una gran arbol de renderizado.
La capa de dispositivo más pequeño debe proteger los flujos donde los mocks pueden estar. Resumen de pruebas no proporciona un tiempo de ejecución React Native completo y no puede probar características nativas. La misma guía recomienda combinar las pruebas de componentes con herramientas E2E como Detox para flujos críticos, incluidos la autenticación, los pagos y la funcionalidad de la aplicación principal.
Un camino de migración práctico
No necesita reescribir un conjunto existente en una sola pasada.
- Mantenga las pruebas comerciales valiosas. Mueva la lógica de estado puro y de dominio a pruebas unitarias enfocadas donde proporcionan feedback claro.
- Sustituya las afirmaciones de implementación primero. Cambia las comprobaciones de propiedades y estado interno en salidas visibles, estado de accesibilidad y resultados de interacción.
- Reduce las capturas de pantalla. Considere solo capturas de pantalla que los revisores puedan comprender y mantener.
- Agregue cobertura de límites nativos. Para cada módulo importante simulado, identifique el comportamiento del dispositivo que aún necesita validación.
- Proteja los viajes críticos. Agregue cobertura E2E para autenticación, pago, navegación principal, permisos y otros flujos donde el comportamiento nativo puede cambiar el resultado.
- Medir pantallas sensibles por separado. Utilice comparaciones de rendimiento repetidas para listas, feeds y rutas de renderizado costosas en lugar de suponer desde la duración de Jest.
Para confianza en la versión, conecta la suite a integración de pruebas de CI/CD y requiera la capa de prueba adecuada antes de enviar. Si una corrección de JavaScript o de activos 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 rollout y protección de rollback. Ese flujo de entrega no reemplaza las pruebas de dispositivos de React Native, pero ilustra el mismo principio: valide 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 rollout y protección de rollback. Visite Capgo para ver cómo puede encajar junto con tu componente, pruebas E2E y CI.
