¿Cómo implementar AndroidCI paso a paso?
Implemente Android CI paso a paso
La cadena de compilación de CI en Android es consistente con otras plataformas y aún incluye etapas de compilación, prueba, inspección,
implementación y cada una de Todas las etapas de retroalimentación se mantienen transparentes para todo el equipo.
El orden de ejecución de cada paso en CI debe ser tal que el que tenga el menor tiempo de ejecución se ejecute primero. Si el tiempo de ejecución es corto, generalmente se puede ejecutar antes de enviar el código y la tasa de error es relativamente baja, por lo que debe ejecutarse primero tanto como sea posible. De esta manera, las fallas llegarán antes y se verificarán más cosas antes de que falle cada operación de CI. El flujo de trabajo de CI en la imagen de arriba se basa en dicho principio.
Preparación del entorno
* Instale el entorno operativo Java y Android en el servidor CI
* Instale la herramienta de compilación; este artículo utiliza Ant para practicar
* Configurar el servicio CI. Este artículo utiliza el servicio de CI de código abierto Jenkins (Hudson).
* Jenkins puede satisfacer completamente las necesidades funcionales y es simple y fácil de usar.
*Instalar entorno Ruby. La herramienta de prueba funcional utilizada en este artículo está implementada en base a Ruby.
Paso 1: Construcción continua
El propósito de la construcción continua es generar automáticamente la última aplicación ejecutable en cualquier momento. Aunque hay tantos calificadores para expresar las condiciones de verificación para completar este paso, de hecho, solo se necesitan tres pasos para completarlo.
La primera es actualizar el código. Jenkins ya es compatible con SVN y Git, dos herramientas de administración de código de uso común. El segundo es usar scripts de compilación para compilar paquetes de instalación. Android ha sido muy considerado e incluso preparó scripts de compilación Ant para nosotros. Y debido a las especificaciones de la estructura de paquetes de Android, también elimina en gran medida la inconsistencia de las organizaciones de proyectos en el entorno de cada desarrollador. El tercero es continuar ejecutando los dos primeros pasos. Solo ejecutando los dos primeros pasos inmediatamente cada vez que hay algún cambio en el código podemos garantizar que se pueda proporcionar un paquete de instalación ejecutable en cualquier momento.
La construcción continua es más fácil de implementar, pero los resultados que logra siguen siendo muy buenos. Los desarrolladores pueden utilizar el mismo script para generar rápidamente paquetes de instalación localmente, lo que también reduce en gran medida el problema de "esto funciona bien en mi máquina". Para los evaluadores, el último paquete de prueba se puede obtener en cualquier momento sin esperar a que los desarrolladores encuentren tiempo para hacerlo. Para la gente de productos, estos últimos paquetes se pueden aprovechar para obtener comentarios tan pronto como los desarrolladores los completen. Incluso puedes iniciar la experiencia después de completar algunas funciones.
Mejores prácticas:
* Cree el proyecto completo después de cada envío. Las confirmaciones aquí deben contener cambios menores.
* Todos siguen la misma secuencia de compilación y utilizan el mismo conjunto de scripts de compilación
* Ejecute el mismo conjunto de scripts cada vez que compilan
Paso 2: Continuar probando
La prueba continua es un método para recopilar rápidamente el estado de salud del software a través de medios automatizados. Las pruebas continuas sirven para verificar si la función del paquete creado es utilizable, no solo para instalarse y ejecutarse. Las pruebas de aplicaciones se pueden realizar desde tres niveles: UI,
Función y Código. La relación de peso entre estos tres niveles se puede diseñar con referencia a la pirámide de pruebas.
De acuerdo con el principio de ejecutar el más rápido primero como se mencionó anteriormente, estos tres niveles de pruebas deben organizarse en el CI en el orden de prueba unitaria, prueba funcional y prueba de interfaz de usuario.
implementar.
1. Agregar prueba unitaria
La prueba unitaria
es la prueba con el costo de ejecución más bajo y la cobertura más completa de casos de prueba. Fomentar el uso de pruebas unitarias para cubrir casos de uso siempre que sea posible.
La primera opción para las pruebas unitarias en Java es usar JUnit, pero debido a que el código del proyecto de Android
tiene una fuerte dependencia del SDK, hay muy poco código que pueda cubrirse simplemente usando JUnit para pruebas unitarias. Para aliviar la dependencia del SDK, es natural considerar la introducción de un marco simulado como Mockito. Pero incluso con la ayuda de Mockito, la carga de trabajo de escribir pruebas unitarias sigue siendo enorme porque hay demasiados objetos de los que es necesario burlarse. Y los objetos de Android no se pueden crear en la JVM.
En este momento, se puede utilizar el marco de prueba unitaria de Robolectric, que mejorará en gran medida la cobertura de la prueba unitaria y, en teoría, puede alcanzar el 100%. Robolectric se basa en JUnit y completa el código auxiliar para Android
SDK. Después de usar el método stub, los componentes de Android se pueden crear y ejecutar en la JVM sin ejecutarse en la plataforma Android. Esto también significa que TDD se puede utilizar en el desarrollo de Android para mejorar aún más la cobertura de las pruebas unitarias. El marco usa JUnit exactamente igual y tiene el mismo rendimiento de ejecución.
Debido a que Robolectric bloquea el SDK, puede verificar completamente el estado del componente e incluso operar el componente al escribir pruebas unitarias. La siguiente prueba es una prueba del evento de clic en el botón y verifica el estado de la Actividad.
El orden de ejecución de cada paso en CI debe ser tal que el que tenga el menor tiempo de ejecución se ejecute primero. Si el tiempo de ejecución es corto, generalmente se puede ejecutar antes de enviar el código y la tasa de error es relativamente baja, por lo que debe ejecutarse primero tanto como sea posible. De esta manera, las fallas llegarán antes y se verificarán más cosas antes de que falle cada operación de CI. El flujo de trabajo de CI en la imagen de arriba se basa en dicho principio.
Paso 1: Construcción continua
El propósito de la construcción continua es generar automáticamente la última aplicación ejecutable en cualquier momento. Aunque hay tantos calificadores para expresar las condiciones de verificación para completar este paso, de hecho, solo se necesitan tres pasos para completarlo.
La primera es actualizar el código. Jenkins ya es compatible con SVN y Git, dos herramientas de administración de código de uso común. El segundo es usar scripts de compilación para compilar paquetes de instalación. Android ha sido muy considerado e incluso preparó scripts de compilación Ant para nosotros. Y debido a las especificaciones de la estructura de paquetes de Android, también elimina en gran medida la inconsistencia de las organizaciones de proyectos en el entorno de cada desarrollador. El tercero es continuar ejecutando los dos primeros pasos. Solo ejecutando los dos primeros pasos inmediatamente cada vez que hay algún cambio en el código podemos garantizar que se pueda proporcionar un paquete de instalación ejecutable en cualquier momento.
La construcción continua es más fácil de implementar, pero los resultados que logra siguen siendo muy buenos. Los desarrolladores pueden utilizar el mismo script para generar rápidamente paquetes de instalación localmente, lo que también reduce en gran medida el problema de "esto funciona bien en mi máquina". Para los evaluadores, el último paquete de prueba se puede obtener en cualquier momento sin esperar a que los desarrolladores encuentren tiempo para hacerlo. Para la gente de productos, estos últimos paquetes se pueden aprovechar para obtener comentarios tan pronto como los desarrolladores los completen. Incluso puedes iniciar la experiencia después de completar algunas funciones.
Mejores prácticas:
* Cree el proyecto completo después de cada envío. Las confirmaciones aquí deben contener cambios menores.
* Todos siguen la misma secuencia de compilación y utilizan el mismo conjunto de scripts de compilación
* Ejecute el mismo conjunto de scripts cada vez que compilan
Paso 2: Continuar probando
La prueba continua es un método para recopilar rápidamente el estado de salud del software a través de medios automatizados. Las pruebas continuas sirven para verificar si la función del paquete creado es utilizable, no solo para instalarse y ejecutarse. Las pruebas de aplicaciones se pueden realizar desde tres niveles: UI,
Función y Código. La relación de peso entre estos tres niveles se puede diseñar con referencia a la pirámide de pruebas.
De acuerdo con el principio de ejecutar el más rápido primero como se mencionó anteriormente, estos tres niveles de pruebas deben organizarse en el CI en el orden de prueba unitaria, prueba funcional y prueba de interfaz de usuario.
implementar.
1. Agregar prueba unitaria
La prueba unitaria
es la prueba con el costo de ejecución más bajo y la cobertura más completa de casos de prueba. Fomentar el uso de pruebas unitarias para cubrir casos de uso siempre que sea posible. La primera opción para las pruebas unitarias en Java es usar JUnit, pero debido a que el código del proyecto de Android
tiene una fuerte dependencia del SDK, hay muy poco código que pueda cubrirse simplemente usando JUnit para pruebas unitarias. Para aliviar la dependencia del SDK, es natural considerar la introducción de un marco simulado como Mockito. Pero incluso con la ayuda de Mockito, la carga de trabajo de escribir pruebas unitarias sigue siendo enorme porque hay demasiados objetos de los que es necesario burlarse. Y los objetos de Android no se pueden crear en la JVM.
En este momento, se puede utilizar el marco de prueba unitaria de Robolectric, que mejorará en gran medida la cobertura de la prueba unitaria y, en teoría, puede alcanzar el 100%. Robolectric se basa en JUnit y completa el código auxiliar para Android
SDK. Después de usar el método stub, los componentes de Android se pueden crear y ejecutar en la JVM sin ejecutarse en la plataforma Android. Esto también significa que TDD se puede utilizar en el desarrollo de Android para mejorar aún más la cobertura de las pruebas unitarias. El marco usa JUnit exactamente igual y tiene el mismo rendimiento de ejecución.
Debido a que Robolectric bloquea el SDK, puede verificar completamente el estado del componente e incluso operar el componente al escribir pruebas unitarias. La siguiente prueba es una prueba del evento de clic en el botón y verifica el estado de la Actividad.
El siguiente paso es integrar Robolectric en CI y dejar que verifique el estado del programa. Robolectric sigue siendo esencialmente JUnit, pero ¿con más objetos auxiliares?
. Entonces nuestro método para integrar Robolectric es exactamente el mismo que el de JUnit. Simplemente cree una tarea Ant y ejecútela en Jenkins. Esta tarea Ant es la siguiente:
Después de integrar estas pruebas en CI, no se puede olvidar el paso más importante de recopilar los resultados. Como se mencionó anteriormente, Calabash también puede generar informes de acuerdo con las especificaciones del informe de prueba unitaria. Además, Robolectric en sí es una extensión del marco JUnit y el informe también se genera de acuerdo con las especificaciones del informe de prueba unitaria.
Los informes de las pruebas unitarias y de funciones se pueden recopilar mediante la prueba JUnit.
Para obtener informes de cobertura de pruebas unitarias, Cobertura es una buena opción. Agregar
Puede obtener un informe claro de cobertura de pruebas unitarias de Jenkins
2 Agregar prueba de función
Android le proporciona un conjunto de pruebas de integración del marco de integración de Android. marco de pruebas
. Sin embargo, este marco no integra Cucumber, lo que resulta en que cada prueba de función adicional requiera un mayor trabajo de desarrollo y mantenimiento. Una implementación tan costosa de la prueba de función retrasará en gran medida el progreso del desarrollo y, eventualmente, la prueba de función se abandonará debido al progreso del proyecto. Tales consecuencias deben ser indeseables.
Actualmente, han aparecido una variedad de herramientas de prueba de Functiong Testing en la plataforma Android, como Native Driver, Robotium,
Calabash, etc. Después de intentar comparar, finalmente se eligió Calabash Android como solución.
Calabash
Android es la implementación de Cucumber en la plataforma Android. Utiliza Ruby para escribir pruebas de funciones y proporciona un conjunto de API para operar elementos de la aplicación Anadroid.
3. Agregar prueba de UI
Android salió recientemente de la herramienta de prueba de UI UIAutomator. Esta herramienta solo es compatible con plataformas Android 4.1 y superiores. Teniendo en cuenta que las versiones 2.3 y 4.0 siguen dominando el mercado, actualmente no puede satisfacer las necesidades de todos. Además, el costo de desarrollo de aplicar esta herramienta para implementar pruebas de UI sigue siendo alto. El autor no recomienda el uso de esta herramienta por el momento, pero debe prestar atención a su desarrollo.
Además, el método de prueba basado en el mecanismo de grabación y reproducción también se puede utilizar para pruebas de UI. Sin embargo, cuando el método de grabación y reproducción se enfrenta a una rápida iteración de funciones, el trabajo de mantenimiento aumentará considerablemente y se puede decir que este costo de mantenimiento es insoportable, por lo que este método de prueba no se integrará en CI aquí.
En la actualidad, no existe ningún método satisfactorio para probar la interfaz de usuario en Android. Si valora más el éxito de la interfaz de usuario, puede invertir en el uso de UIAutomator para las pruebas de la interfaz de usuario.
Mejores prácticas:
*
Divida las pruebas en pruebas unitarias, pruebas de componentes, pruebas funcionales y pruebas de sistemas. Las pruebas unitarias deben activarse cada vez que se envían. Se pueden activar otras pruebas cada vez que se envían o se ejecutan periódicamente según su tiempo de ejecución e importancia.
* Prioriza las pruebas más rápidas.
*Haz que las pruebas funcionales sean repetibles. De lo contrario, el costo de mantenimiento será demasiado alto y será abandonado. Si los datos de fondo no son repetibles, los datos se pueden extraer en un conjunto de datos y restablecerse antes de cada ejecución.
* Al escribir pruebas, cada afirmación solo emite un juicio, de modo que se pueda aclarar el propósito de cada prueba y localizar rápidamente las fallas de las pruebas.
Paso 3: Inspección continua La inspección continua consiste en detectar y proporcionar retroalimentación sobre el propio código. La detección verifica principalmente la calidad del código en múltiples dimensiones, como el estilo del código, las especificaciones de programación, la reutilización del código y las mejores prácticas en el lenguaje del código, mediante el análisis estático del código.
Como herramienta de detección de calidad de código fuente abierto, Sonar cubre 7 métodos de detección de calidad de código. Esto satisface plenamente la detección y análisis de la calidad del código en la plataforma Android. Sonar se divide en dos partes: una es la herramienta de análisis de código y la otra es el servidor para el análisis y visualización de datos.
Mejores prácticas:
* Hacer que la cobertura de las pruebas y los resultados del análisis de código sean transparentes
* Reducir continuamente la complejidad del código
* Promover continuamente la evolución de diseño
* Mantener continuamente la estructura del código
* Reducir continuamente la duplicación de código
Paso 4: Implementación continua
Porque las aplicaciones de Android son publicadas por los usuarios que las descargan e instalan manualmente desde la Appstore, lo que hace que las aplicaciones de Android
no se puedan implementar directamente en los teléfonos móviles de los usuarios. Además, la Appstore necesita revisar la aplicación en línea y no puede continuar publicándola. Por lo tanto, la implementación continua en Android tendrá como objetivo el lanzamiento continuo de paquetes instalables.
Para los fines anteriores, solo necesita encontrar la herramienta de administración de paquetes de instalación adecuada según los recursos de su propio proyecto. Como este artículo utiliza Dropbox para administrar todos los paquetes de instalación.
Como plataforma de almacenamiento en la nube, Dropbox puede descargar fácilmente archivos almacenados en él en dispositivos terminales Android. Al mismo tiempo, el propio Dropbox también puede cargar el paquete de instalación.
Paso 5: Comentarios continuos
Los comentarios son el comienzo de todas las mejoras. Todos deben obtener los comentarios que les interesan antes de que se puedan implementar las mejoras. El propósito de la retroalimentación continua es mantener a todos al tanto del estado del proyecto. De hecho, los propietarios del proyecto están dispuestos a conocer el estado actual del proyecto, por lo que CI debe hacer que la situación del proyecto sea transparente y notificar diferentes comentarios a los miembros relevantes.
Las diferentes etapas de la CI producen retroalimentación desde diferentes dimensiones, como informes de pruebas unitarias, cobertura de pruebas, etc.
En esta práctica, estos comentarios se muestran de forma transparente en la página de inicio del proyecto. La razón por la que no se notifica a todos estos comentarios por correo electrónico es porque los miembros del equipo han desarrollado el hábito de verificar el CI.
Si solo envía un correo electrónico a todos para explicar el estado del proyecto, debe ser para decirles a todos "¿Se devolvieron todos los pasos de CI correctamente?". Dichos comentarios incluyen información importante, como que la compilación es correcta, que se aprobaron todas las pruebas y que el paquete de instalación está listo. Es necesario que todos conozcan esta información, especialmente cuando falla la ejecución de CI. El propio Jenkins ya proporciona un método de transparencia simple y efectivo. El proyecto es azul para indicar que pasó y rojo para indicar que un paso falló.
Hay muchas formas de notificar comentarios y no es necesariamente necesario utilizar la notificación por correo electrónico. Puede encontrar formas más divertidas de reproducir música y configurar luces de alarma. Reproducir una pieza musical interesante y encender luces de alarma de diferentes colores después de que cada compilación tenga éxito o falle. Ambos métodos son formas simples y efectivas de permitir que todos en el proyecto obtengan la información más crítica.