Ir al contenido

Preguntas frecuentes

Respuestas breves a las dudas que aparecen al evaluar o empezar a usar lynkeus. Cada una enlaza a la página que la desarrolla.

¿En qué se diferencia de Detox, Maestro o Appium?

Sección titulada «¿En qué se diferencia de Detox, Maestro o Appium?»

Cubre el mismo terreno: manejar un build real de extremo a extremo. La diferencia es desde dónde. Esas herramientas actúan a través del sistema operativo; lynkeus actúa desde dentro de la app.

De ahí salen su ventaja y su condición. Es rápido, porque nada sale del proceso para decidir el paso siguiente, y afirma sobre hechos (rutas, valores, peticiones) en lugar de imágenes. A cambio, necesita un build de depuración con el agente adentro.

No. El módulo nativo se compila vacío fuera de los builds de depuración, y el JavaScript del agente nunca se evalúa cuando enabled es falso.

En iOS, el código que genera los toques está dentro de #if DEBUG: los símbolos no existen en el binario de producción. En Android, el módulo se niega a funcionar si la app no es depurable. Más en Seguridad.

¿Puedo probar mi build de producción con lynkeus?

Sección titulada «¿Puedo probar mi build de producción con lynkeus?»

No, y es consecuencia directa de la respuesta anterior. lynkeus prueba el build de depuración de tu app.

lynkeus es de código abierto, con licencia MIT. El agente, el CLI y el host sin pantalla no tienen costo.

El servicio de reportes alojados en lynkeus.io es aparte y opcional. Tiene dos planes:

Free Team
Capturas de pantalla sí sí
Video de cada caso no sí
Historial 7 días 90 días
Proyectos uno sin límite

El plan Team es una suscripción por organización. Más en Reportes.

¿Necesito el servicio de reportes para usarlo?

Sección titulada «¿Necesito el servicio de reportes para usarlo?»

No. lynkeus case run imprime el resultado en la terminal y, con --out <dir>, escribe la ejecución como archivos que puedes leer con tus propias herramientas. El servicio agrega la vista para personas y el historial.

React Native 0.76 o posterior. En iOS, con la Nueva Arquitectura. El CLI y el host sin pantalla necesitan Node 22 o posterior.

Sí, en iOS y en Android, con un development build. No funciona en Expo Go, porque el agente tiene código nativo. No hace falta ningún config plugin. Los pasos están en Instalación en Expo y los límites en Expo.

No es obligatorio. Un elemento también se puede señalar por su texto, por su índice en el listado de la pantalla o por un punto.

Aun así, el testID es la forma más estable: no cambia con el idioma ni con la redacción. Agrégalo en los controles que tus tests tocan.

No. El agente se monta con una llamada a auto() en el punto de entrada de la app, y ninguna pantalla renderiza nada adicional. El comando lynkeus init agrega esa llamada por ti (desde la versión 0.3.0). En una app de React Native agrega también un plugin a babel.config.js, que es lo que hace llegar el token a la app.

¿Con qué librerías de navegación funciona?

Sección titulada «¿Con qué librerías de navegación funciona?»

Con React Navigation, sin configuración: auto() encuentra el contenedor por su cuenta. Las rutas de expo-router también se reconocen.

Con otro enrutador, puedes escribir un adaptador de navegación y pasárselo al componente <Lynkeus>. Sin adaptador, lynkeus sigue leyendo la pantalla, tocando y esperando elementos; lo que no tiene son nombres de rutas. Más en API del agente.

Para que solo tu driver pueda manejar la app. El agente atiende únicamente a quien abre la conexión con el mismo secreto, lo que deja afuera a cualquier otro proceso de tu máquina.

La app lo recibe en la opción token; el CLI lo lee de LYNKEUS_TOKEN. El host sin pantalla no arranca sin él.

Porque React Native no le da a la app ningún entorno: dentro de un bundle, process.env.LYNKEUS_TOKEN vale undefined mientras nada escriba ahí el valor. El plugin lynkeus-agent/babel lo escribe, en un bundle de desarrollo solamente, con el valor que la variable tiene donde arranca Metro. Después de cambiar ese valor, arranca Metro una vez con --reset-cache.

Expo no lo necesita: la app lee EXPO_PUBLIC_LYNKEUS_TOKEN.

¿Qué pasa si el token llega vacío a la app?

Sección titulada «¿Qué pasa si el token llega vacío a la app?»

El agente queda apagado, y la app lo dice en su log con lynkeus: the app passed a token and it is empty. No pasa a atender a cualquiera. Desde la terminal lo ves como una app que no se conecta; el arreglo está en Solución de problemas.

El paquete está en el bundle y no hace nada ahí. El módulo nativo se compila sin efecto fuera de los builds de depuración. El cliente, que es todo lo que lee la pantalla y habla con el driver, solo se carga cuando enabled es verdadero, sea cual sea la forma en que la app importa el paquete y lo que Metro esté configurado para incorporar. Y el token nunca se escribe en un bundle de producción. Más en Seguridad.

No. La app es la que se conecta hacia afuera, a tu propia máquina. Dentro de la app nada queda escuchando, y nada es alcanzable desde la red.

No. Los dispositivos físicos no están soportados. El CLI busca un simulador o un emulador encendido, y abrir la app, tomar capturas de pantalla y los comandos os pasan por simctl y adb sobre uno de ellos.

En archivos markdown llamados casos: un encabezado que los identifica y una lista de pasos en YAML. Están pensados para que los lea cualquiera del equipo. Empieza por Tu primer test.

Si prefieres escribirlos en código, lynkeus-client es el cliente de Node sobre el que está construido el CLI. Con él manejas la app desde Jest, Vitest o el ejecutor que ya uses.

Con fixtures: datos de prueba que tu propio comando crea cuando un caso los pide. lynkeus le envía cada pedido como una línea de JSON y lee la respuesta. No necesita saber nada de tu backend. Más en Fixtures.

Sí. lynkeus headless start aloja la app en Node, bajo Jest y React Native Testing Library, y case run --host lo hace por ti durante una ejecución. La capa nativa queda reemplazada por mocks, así que hay cosas que solo un simulador puede probar. Una app con expo-router no puede correr en este host. Más en Sin pantalla (headless).

¿El mismo test sirve para iOS, Android y sin pantalla?

Sección titulada «¿El mismo test sirve para iOS, Android y sin pantalla?»

Sí. Un caso no dice dónde corre la app. Los pocos pasos que solo necesita un lado se marcan con on: ios, on: android, on: device o on: headless, y en los demás se omiten.

El caso se detiene en ese paso y lynkeus guarda la pantalla tal como estaba, las peticiones que había hecho la app y el motivo: el objetivo estaba tapado, oculto detrás de una capa, deshabilitado o ausente. Después el caso se ejecuta una vez más antes de contar como fallido.

A mano, lynkeus why <objetivo> hace la misma pregunta en cualquier momento.

¿Cómo distingo un test intermitente de uno roto?

Sección titulada «¿Cómo distingo un test intermitente de uno roto?»

Un caso que falla y pasa en el reintento queda marcado en el resumen como aprobado en el reintento. lynkeus lleva además un registro de cómo le fue a cada caso a lo largo de las ejecuciones. Más en Tests intermitentes.

¿Por qué cada comando tarda más de un segundo si los pasos son de milisegundos?

Sección titulada «¿Por qué cada comando tarda más de un segundo si los pasos son de milisegundos?»

Porque un comando suelto paga por arrancar un proceso y conectarse, cerca de 1,5 segundos. El paso en sí cuesta milisegundos.

Para encadenar muchos, lynkeus session mantiene una sola conexión abierta y cada paso baja a unos 50 ms. lynkeus case run ya trabaja así. Más en Manejar la app.

¿Puedo correr varias ejecuciones en la misma máquina?

Sección titulada «¿Puedo correr varias ejecuciones en la misma máquina?»

Sí. Define LYNKEUS_PORT con un valor distinto para cada pareja de app y driver. Cada pareja es independiente.

De dos maneras, que se pueden combinar. Con el host sin pantalla no necesitas simuladores y puedes repartir la suite entre núcleos. Con un simulador o un emulador pruebas además la capa nativa. Las dos están en CI.

Sí. lynkeus mcp sirve los comandos como herramientas MCP. El modelo recibe elementos estructurados en lugar de píxeles, así que decide el paso siguiente a partir de hechos. Más en Agentes de IA.

¿Qué registra lynkeus de las peticiones de mi app?

Sección titulada «¿Qué registra lynkeus de las peticiones de mi app?»

El método, la ruta, el código de respuesta y la duración. Nunca los encabezados ni los cuerpos, y los valores sensibles de la consulta se ocultan. El valor de un campo con secureTextEntry también aparece enmascarado. Más en Seguridad.

No, y es deliberado. No tiene una lista de tus pantallas ni sabe qué es un usuario en tu app. Lo que requiere conocer el producto (cómo iniciar sesión, qué datos necesita un caso) lo aportas tú, en lynkeus.config.json y en tu comando de fixtures.

El repositorio no recibe contribuciones: los issues están desactivados y los pull requests se cierran automáticamente. Puedes hacer un fork bajo los términos de la licencia MIT.