foto de Unsplash para "tubería"
Enfoque general
Hola Estoy comenzando una serie de publicaciones sobre canalizaciones en desarrollo y no solo eso ayuda a verificar la calidad de las aplicaciones móviles que se están desarrollando. La idea principal es resaltar todos los enfoques de desarrollo móvil que son relevantes ahora: desarrollo nativo para Android e iOS, React Native, Xamarin y Flutter. Comenzaré con Android, pero primero me gustaría dar una idea general de lo que se trata todo esto.
Tenga en cuenta que esta es una descripción general de las herramientas y prácticas que pueden ser útiles durante el desarrollo de aplicaciones de Android, y no un tutorial sobre cómo configurar estas herramientas.
¿Para qué es todo?
Comencemos con la conocida verdad: cuanto más tarde encuentre un defecto en la aplicación, más costoso será solucionarlo. Supongamos que ha descubierto un error que ya está en producción. Sus probadores necesitan reproducir este error localmente, registrarlo, priorizarlo, pasarlo a los desarrolladores, y ellos, a su vez, deben arreglarlo, hacer un nuevo ensamblaje, devolverlo a los probadores para que estén convencidos de que todo está solucionado, y luego hacer la versión de compilación, y solo entonces envíe la nueva versión a los usuarios.
Se podrían ahorrar muchas horas de trabajo si tuviera mecanismos para evitar la aparición de errores desde el principio. No digo que haya una bala de plata que elimine todos los errores, esto es imposible. Pero lo que es posible es erigir barreras (también conocidas como puertas de calidad) que aumentan la probabilidad de detectar errores en su código lo antes posible.
En la computadora del desarrollador
Como desarrollador, siempre trabaja en su máquina con un IDE y herramientas de línea de comandos. Veamos qué existe para los desarrolladores de Android.
Android Studio
Esta es ahora la opción predeterminada para el desarrollador de Android, y dado que se basa en la plataforma IntelliJ, hay muchas inspecciones para Java, Kotlin y XML. Le aconsejo que acepte en un equipo las reglas específicas que desea usar, configúrelas en una computadora y cargue el archivo settings.jar con estas reglas en su sistema de control de versiones o algún tipo de herramienta de trabajo colaborativo (como Confluence).
Configuración de inspección en Android Studio
AS también tiene soluciones rápidas que se pueden aplicar a su código presionando Alt + Enter.
Ejemplo de arreglo rápido de Android Studio
Pelusa de Android
Esta es una herramienta de análisis estático específicamente para el desarrollo de Android, lista para usar con cientos de reglas, cualquiera de las cuales puede usar. Lint también se puede iniciar desde la tarea de Gradle (tarea), y dar indicaciones directamente en Android Studio, y generar un informe. Tiene muchos controles, divididos en categorías: seguridad, internacionalización, usabilidad, rendimiento ...
Pero la capacidad de agregar sus propias reglas lo hace especialmente poderoso. Por ejemplo, Room tiene su propio conjunto de reglas, la biblioteca de registro de Timber tiene la suya propia. Puede crear reglas para su equipo o proyecto y asegurarse de que nadie cometa ciertos errores típicos. (Por cierto, pronto en la conferencia de Mobius habrá un informe sobre esto, explicando tanto el lado teórico como el práctico).
Ejemplo de informe de Android Lint
Más análisis estático
Por supuesto, hay muchas herramientas de análisis estático diseñadas no específicamente para Android, sino en general para Java y Kotlin : PMD , FindBugs (abandonado, use SpotBugs ), Checkstyle , Ktlink , Detekt y otros. Elija a su gusto, integrelo en su cartera y garantice su uso real (¿cómo exactamente? Siga leyendo).
Informe de ejemplo de FindBugs
Pero no es suficiente tener una herramienta que proporcione datos sobre lo que necesita ser reparado. También encontrará útil la siguiente información:
- ¿Cómo cambia la cobertura del código con las pruebas con el tiempo?
- ¿Cuánto tiempo me llevará solucionar todos los problemas encontrados?
- ¿Cuánto código duplicado hay en el proyecto?
- ¿Cómo extiendo mis reglas a varios equipos?
Y muchos otros En EPAM Systems nos centramos en la calidad, por lo que hemos elegido SonarQube como herramienta para responder estas preguntas. Para otros beneficios de SonarQube, haga clic aquí .
Prueba unitaria
Esperemos que no tenga que volver a asegurarle que su maldito código necesita pruebas unitarias por varias razones . No importa si sigue el TDD, se adhiere al principio de la pirámide de prueba o la nueva idea del hongo de prueba . No es tan importante el nivel de cobertura que establezca como su objetivo, en cualquier caso, sus pruebas unitarias son un componente necesario. Entonces, ¡debes escribirlos y ejecutarlos! Afortunadamente, durante 11 años de evolución, obtuvimos un mecanismo bastante conveniente para ejecutar pruebas desde el complemento Gradle y Android Gradle.
En el proyecto de Android, el proyecto predeterminado es testDebugUnitTest (para usted, por supuesto, puede diferir según los sabores), y es ella quien ejecuta las pruebas. Asegúrese de usarlo y que la cobertura del código aumenta con el tiempo. La ventaja de las pruebas unitarias de Java es que funcionan en la estación de trabajo JVM y no en Dalvik / ART, lo que brinda una ventaja en velocidad.
En el caso de las pruebas unitarias de Android, hay un problema fundamental: la dependencia del SDK de Android. Esta es una de las razones por las cuales todos estos enfoques de la capa de IU aparecieron como MVP, MVVM, MVI y otros MV *. El problema específico que depende de la clase en Android es que las pruebas unitarias simplemente caen debido al uso de trozos de este Android, que simplemente arrojan una excepción. Por supuesto, hay un par de opciones: omitir las pruebas para esta clase, o extraer parte de la lógica en otras clases, o crear interfaces para clases dependientes de Android para probar alguna lógica de alto nivel, o usar Robolectric (que está lejos de ser ideal). Otra opción es utilizar pruebas instrumentadas, que pueden ser adecuadas para verificar el comportamiento de una Actividad, pero la tendencia actual es que la Actividad no debe contener pruebas.
A la cuestión de la cobertura: desea saber qué es en su momento y cómo cambia con el tiempo, por lo que también necesitaría una herramienta para esto. Hasta donde yo sé, jacoco es un estándar de la industria para Java, y tiene soporte para Kotlin.
Pruebas instrumentadas
Estas pruebas se ejecutan en el emulador de Android, lo que les permite usar el Marco de Android. Desafortunadamente, son lentos e inestables (debido a algunos problemas con el emulador), por lo que la mayoría de los desarrolladores que conozco personalmente intentan evitarlos. Pero su soporte está en Gradle y Android Studio, por lo que para usted, pueden ser adecuados.
Auditoria de seguridad
Además de los errores simples, errores tipográficos, problemas con copiar y pegar y similares, también hay una gran categoría de problemas a los que debe prestar atención: seguridad. Por supuesto, Android Lint ya ofrece algunos consejos relevantes, pero es mejor cuidar herramientas especializadas específicamente para esta tarea. Estas herramientas pueden funcionar tanto en modo estático como dinámico; dependiendo de sus requisitos de seguridad, es posible que desee utilizar cualquiera de estos modos, o ambos. Es posible que desee comenzar, por ejemplo, con Mobile Security Framework , y luego considerar opciones pagas.
Afortunadamente, hay una lista de herramientas de análisis estático compiladas directamente por OWASP. Por ejemplo, puede elegir Buscar errores de seguridad o utilizar el proyecto OWASP SonarCube .
Verificar verificaciones
Como dije, cuanto más corto sea el ciclo de retroalimentación, menos tiempo y dinero gastará en corregir errores. Por lo tanto, quiero asegurarme de que el código corresponde a la calidad de producción incluso antes de que llegue al repositorio o incluso se comunique localmente. Por supuesto, simplemente puede pedirles a sus desarrolladores que realicen comprobaciones, pero hay una opción mucho mejor: ganchos Git.
Sugiero agregar un enlace de precompromiso para todas las comprobaciones que discutimos anteriormente: pelusa, análisis de código estático y pruebas unitarias. Un ejemplo del proceso de configuración se puede encontrar aquí .
Canalización CI / CD
Es muy difícil imaginar un proyecto de Android sin una canalización de CI / CD. Su objetivo es repetir todas las comprobaciones anteriores en la etapa de montaje. Hay varias razones para esto:
- Los ganchos Git se pueden eludir fácilmente con la opción --no-verificar
- El código puede pasar con éxito todas las comprobaciones localmente, pero presenta problemas después de la fusión.
- Necesita informes de prueba y cobertura
Ejemplo de informe en bitrise.io
Afortunadamente, solo necesita mencionar estas comprobaciones de seguridad directamente en el script de compilación de Gradle, o invocar las tareas correspondientes en su canalización de CI / CD. Si tiene dificultades para construir una tubería, recientemente hice una presentación en la conferencia DevOops sobre DevOps móvil en 2019.
Por favor también haga lo siguiente:
- Ejecute todas las comprobaciones de solicitudes de extracción. No permita fusionar ninguna solicitud que viole cualquiera de las reglas. Esto es muy importante: si la regla no se ejecuta, entonces, de hecho, no existe.
- Ejecute todas las comprobaciones durante el montaje y la implementación. No desea bajar su barra de calidad.
- Si la compilación se rompe, esta es la primera prioridad. El equipo debe solucionar el problema de inmediato, ya que viola su práctica de entrega continua y evita que el equipo escriba código de calidad.
¡Y buena suerte mejorando tu código!
Si te gustó este artículo, sígueme en Twitter para que no te pierdas lo siguiente. Y si va a estar en Moscú en diciembre o puede venir, ¡venga a nuestra conferencia Mobius y descubra muchas otras cosas sobre el desarrollo para Android (e iOS)!
PD: Gracias a vixentael por abordar problemas de seguridad, a Alexei Nikitin por su revisión y comentarios, a Alexander Bakanov por la corrección de pruebas.