Con ProGuard, ¿cuál es el impacto en la estrategia de pruebas?
He tenido que introducir recientemente ProGuard en Android debido a problemas con Scala en Android. Necesito ProGuard para su característica que encoge, que elimina las clases presumiblemente no utilizadas. Estoy muy preocupado por el impacto de la eliminación de clases sobre la capacidad de prueba.
Tal como está, escribo pruebas de unidad que se ejecutan en el host y las pruebas de aceptación que ejecutan la aplicación totalmente integrada en la plataforma de Android.
- ¿Cómo se pueden reducir las aplicaciones scala para Android en tamaño de archivo?
- Android Scala y Gradle
- Android studio dalvik vm no puede encontrar la clase
- Llamar a diferentes constructores de Java de Scala con Android
- Tiempo de construcción largo con sbt android-plugin
Normalmente, me sentiría cómodo con una cobertura de prueba de unidad relativamente completa y una cobertura de prueba de aceptación irregular. Sin embargo, dado que en mi código utilizo la inyección de dependencia de Guice fuertemente, hasta ahora ha sido mi experiencia que ProGuard elimina el código de una manera que es difícil para mí predecir. Debido a esto es muy probable que me causa introducir bugs.
Esto me lleva a creer que necesito escribir pruebas de aceptación / plataforma que alcancen cobertura completa porque en cualquier momento, puede haber una clase que falta.
¿Otros tienen esta experiencia? Si es así, ¿cuál ha sido su estrategia de pruebas? O con experiencia, ¿se vuelve más seguro de que las clases que ProGuard está eliminando son realmente innecesarias?
- No se puede encontrar el método en la actividad
- ¿Es Scala para mí? (Desarrollador C # con enfoque en el estilo funcional / OOP)
- Acelerar el proceso dex con archivos jar, ¿es posible?
- Proyecto LibGDX escrito en Scala, en Android, con IntelliJ
- ¿Cómo excluir dependencias transitivas de otro subproyecto en compilaciones multiproyecto?
- Biblioteca "libmaliinstr.so" no encontrado
- Cómo bajar la versión proguard en androide gradle estudio?
- Los actores de Scala en android
ProGuard no romperá su aplicación hasta que intente utilizar la reflexión o Class # forName en las clases eliminadas y / o los miembros ofuscados.
De mi experiencia (con Scala ofuscado en Android también) es realmente fácil detectar problemas causados por ProGuard a su aplicación de Android mediante los simples tests de humo. Sabes qué bibliotecas incluyes en tu proyecto. Si algunos de ellos usan la reflexión o Clase # forName – realice una prueba de humo en ellos. A continuación, excluya las clases / miembros necesarios de la configuración de ProGuard.
Recuerde también que puede automatizar las pruebas de su proyecto ofuscado utilizando ActivityInstrumentationTestCase2 y el emulador. Si planea utilizar ProGuard en su proyecto, realice siempre pruebas de instrumentación en APK ofuscado.
En conclusión – miedo no. Problemas relacionados con ProGuard son relatividad fácil de detectar.
Hemos estado tanto en las pruebas unitarias como en las pruebas "completas" de nuestra aplicación ProGuard-ed desde hace bastante tiempo, y no hemos tenido problemas "reales". Los únicos problemas que encontramos es cuando usamos algunos métodos de biblioteca en nuestras pruebas que no se usan en la aplicación principal; En estos casos, ProGuard eliminará el código de las bibliotecas y tendríamos que agregar manualmente los métodos específicos a proguard.cfg
.
Oh, y también usamos Guice 🙂
- Strange R.java cuestión causar recurso no es la carga correctamente
- Error de IndexOutOfBoundsException de Android para la vista de lista de filtros de búsqueda