son necesarios los test de UI? Espresso Test Recorder Espresso API Espresso Idling Resources Mock web server Firebase test lab Casos avanzados @_saulmm
manual es tedioso Implica mucho tiempo, es fácil perder tests importantes Permite la refactorización Evita regresiones Tests con gran ‘scope’ Al interactuar cuál usuario, los detalles de implementación no son demasiado importantes @_saulmm
generar tests de UI a partir de interacciones con un dispositivo Código autogenerado mejorable Es necesario mejorar el código generado por ETR, ya que incita a malas prácticas como el uso `Thread.sleep` en nuestros tests @_saulmm
clientes HTTP Mantenido por Square (creadores de OkHttp, Retrofit) Permite servir archivos JSON estáticos en local Se evita salir a internet, razón suficiente para que nuestros tests no sean confiables (flaky tests)
clientes HTTP Mantenido por Square (creadores de OkHttp, Retrofit) Permite servir archivos JSON estáticos en local Se evita salir a internet, razón suficiente para que nuestros tests no sean confiables (flaky tests)
asíncronas ocurren LLamadas a red, operaciones complejas, carga de db, etc. Mediante el componente IdlingResource, podemos decirle a Espresso cuando ha de esperar CountlingIdlingResource.increment() doHeavyWork() CountingIdlingResource.decrement()