Primero una aclaración: soy el cofundador y CEO de testRTC.
Hablando estrictamente, hay 5 formas de probar WebRTC:
- No probarlo (el enfoque más común)
- Prueba manualmente lo que puedas (también bastante común)
- Use Selenium y una cuadrícula de Selenium autohospedada
- Haz lo anterior, pero en Saucelabs o similar
- Utilice un servicio de prueba administrado de WebRTC (como testRTC, ¿mencioné que trabajo allí?)
Revisemos las alternativas rápidamente. Me mantendré lo más objetivo posible:
- ¿Qué es Snapchat?
- ¿Qué debería escribir un desarrollador nativo de Android junior, que antes no trabajaba en una empresa pero que tomó muchos cursos e hizo aplicaciones, por su experiencia?
- ¿Cuál es el mayor error que cometió cuando trabajó con un desarrollador en su primera aplicación móvil?
- ¿Puedes usar un emulador para probar una aplicación de Android que usa un GPS, o necesitas usar un dispositivo Android?
- ¿Pregunta sobre la creación de aplicaciones móviles con html5?
# 1 – No probarlo
Muchos toman esta ruta, utilizando los desarrolladores que escriben el código y los usuarios iniciales como su equipo de control de calidad. Funciona hasta cierto punto, pero no puede funcionar a largo plazo.
Tampoco prueba muchos problemas que se encuentran solo más tarde durante la producción (aquí se me viene a la mente la configuración incorrecta del relé TURN y el dimensionamiento / escala del servicio).
# 2 – Probar manualmente
Esto es lo que haces cuando tienes un ingeniero de pruebas en la empresa. Le das a él para que haga las pruebas por ti, y él lo hará. Pero manualmente no lo llevará mucho más lejos que no realizar ninguna prueba.
Un buen probador probablemente agregaría alguna máquina Linux local para que actúe como proxy o la casilla transversal NAT de un pobre para verificar estas configuraciones. Incluso podría probar un par de navegadores más en paralelo y probar varias versiones de navegador mientras lo hace.
El resultado final es similar a no probar en absoluto.
# 3 – Use Selenium autohospedado
En este caso, los desarrolladores crean un entorno Selenium. Probablemente usando Selenium Grid. Selenium permite realizar la automatización del navegador, por lo que eso ayudará un poco.
Sin embargo, el desafío es que Selenium no manejará los matices de WebRTC por usted. Aquí hay un par de cosas que hemos hecho de nuestra parte para que los navegadores actúen bien para nuestras necesidades:
- Inyecte audio y video falsos en el navegador
- Recopile métricas a través de getstats de WebRTC (y luego agregue, analice y visualice esos datos para que tengan sentido)
- Maneje errores del navegador con diferentes cosas, como los archivos de video Y4M en Chrome
- Tratar con escenarios en los que desea sincronizar navegadores en la misma sesión (uno inicia sesión en un servicio, obtiene una URL temporal y hace que los otros navegadores se unan a esa URL temporal)
Hay muchas cosas que hacer aquí para obtener una solución decente, y luego deberá mantenerla y actualizarla como parte de su propio servicio.
Si WebRTC está en el centro de lo que haces, y tienes los recursos de ingeniería de sobra, entonces, por supuesto, hazlo.
# 4- Use Saucelabs o similar
Saucelabs funcionará como un servicio de gestión de Selenium, que resuelve parte del dolor de cabeza, pero no resuelve 4 problemas muy importantes para WebRTC:
- ¿Todas las cosas anteriores sobre la recopilación de datos y el trabajo con WebRTC cuando ejecuta su propio Selenium? Tendrás que hacer esto aquí también
- Escalar a 100 o más navegadores en paralelo es casi imposible allí sin una gran cuenta empresarial, por lo que no hay pruebas de estrés real
- Sus máquinas realmente no pueden llegar a 2.5mbps de velocidad de bits de video, por lo que si eres pesado en el video, esto no es para ti
- No hace peer-to-peer. De alguna manera, la forma en que sus redes están configuradas alrededor de los navegadores no lo permite, por lo que gran parte de las pruebas para WebRTC y sus capacidades se pierden
# 5 – Use testRTC
No puede ser objetivo aquí, pero testRTC se creó pensando en WebRTC y en cómo ejecutar pruebas contra él, lo cual tiene sentido.
Compruébelo: resuelve muchos de los problemas de automatización y monitoreo de pruebas relacionados con WebRTC.
