Un blog dedicado a la nutrición y el bienestar.

Mejora tu vida

Prueba de manejo local de Android (Parte 1)

Introducción

Una de las cosas más frustrantes sobre el desarrollo de aplicaciones móviles es encontrar un problema desagradable en una versión recién lanzada y verse obligado a retirarla del mercado. Fue esta frustración la que me llevó a explorar las pruebas automatizadas y, en particular, las pruebas unitarias para la plataforma Android.

El objetivo de las pruebas automatizadas en general, y de las pruebas unitarias en particular, es permitir que las máquinas hagan el trabajo pesado probando los problemas de código automáticamente. La prueba unitaria se enfoca en probar «unidades» de código aisladas sin la necesidad de que se esté ejecutando toda la aplicación. Esto es excelente para probar lógica compleja, especialmente en los casos en que un desarrollador no está 100 % seguro de una parte de su código. En este post quiero explicar una introducción a las pruebas unitarias en la plataforma Android, sin necesidad de un dispositivo físico o emulador para probarlo. el código de prueba actual.

Pruebas de dispositivos versus pruebas sin dispositivos

Antes de sumergirme en los detalles técnicos, quiero decir algunas palabras sobre cómo probar el dispositivo. Mi impresión de leer el Guía de prueba oficial de Android Parece que Google se centra mucho en hacer pruebas en un dispositivo físico o emulador. Tienen una pequeña sección. prueba de unidad local pero esos parecen ser secundarios en importancia (al menos la forma en que se leen). También hay herramientas para facilitar la prueba de dispositivos. Calabaza y google Laboratorio de pruebas en la nube. Prefiere el texto sin un dispositivo en su lugar.

Mi preferencia son las pruebas de unidades locales por varias razones:

1. Son más rápidos porque se ejecutan en la memoria y no requieren un dispositivo físico.
2. Menos problemas de integración al tener que conectarse a un dispositivo físico.
3. Puede ejecutarse en cualquier lugar como un servidor o una computadora portátil para desarrolladores.
4. Se puede ejecutar en paralelo.
5. Más económicas ya que no necesitan dispositivo físico.

Ahora, dicho esto, las pruebas unitarias son realmente excelentes para probar la lógica, pero no tanto para probar la interfaz de usuario actual. Sin duda, hay casos en los que es preferible realizar pruebas en el dispositivo, especialmente cuando se han probado problemas de compatibilidad entre dispositivos.

El pone los cimientos

Dado que la programación de Android se realiza principalmente en Java, las herramientas de prueba de unidades utilizadas en Java también son útiles para Android. Algunas herramientas comunes utilizadas son JUnit y muchas otras bibliotecas creadas para trabajar con él. Me decidí por una combinación de JUnit4 para las pruebas del corazón, afirma J para hacer la declaración más fácil y Mockito por burla..

Para comenzar, configure su archivo Gradle como se describe a continuación. Tenga en cuenta que estas son dependencias de «compilación de prueba», no de «compilación» que le dicen a Gradle que solo se usarán durante la prueba. También tenga en cuenta que uso AssertJ v1 porque este es el Solo versión compatible con Android.

Captura de pantalla 2015-07-20 a las 2.55.55 p. m.

Efectos secundarios de la biblioteca de soporte de pruebas de Android

Antes de discutir la mecánica actual de las unidades de escritura de texto, sería conveniente mencionar un punto importante con respecto a la Biblioteca de soporte de prueba de Android, que se incluye con el complemento de Android para Gradle. Esta biblioteca siempre se incluirá cuando ejecute sus cabezas y stubs todas las clases de Android. El problema es que no proporciona ningún código de ejecución, pero cada vez que intenta acceder a una clase de sistema Android que está siendo pirateada, aparece el siguiente error:

Captura de pantalla 2015-07-20 a las 2.56.09 p. m.

Google te proporciona siguiente explicación:

El archivo android.jar que se usa para realizar pruebas unitarias no contiene ningún código propietario, que es proporcionado por imágenes del sistema Android en dispositivos reales. Sin embargo, todos los métodos lanzan excepciones (por defecto). Esto es para garantizar que sus pruebas unitarias solo prueben su código y no dependan de ningún comportamiento particular de la plataforma Android (que no haya estafado explícitamente, por ejemplo, usando Mockito).

En términos prácticos, esto significa que debe eludir cualquier método de Android al que intente acceder en su código, como describiré más adelante. Sin embargo, hay otro efecto secundario desagradable: la biblioteca de soporte de prueba también incluye código que no es de Android, como org.json.* Class, que genera errores cada vez que intenta hacer algo con objetos JSON. A informe de error fue presentado con Google para esto.

Si está utilizando clases JSON, la solución es como se describe anteriormente Desbordamiento de pilaes incluir manualmente el archivo jar JSON en su archivo gradle de la siguiente manera (Maven no funciona para el complemento v1.1.0 y anteriores):

Captura de pantalla 2015-07-20 a las 2.56.21 p. m.

Si está utilizando el complemento Android Gradle v1.2.3 o posterior, puede usar Maven en su lugar:

Captura de pantalla 2015-07-20 a las 2.56.29 p. m.

Recursos de referencia en el archivo R

Otro problema común que surge es referirse a los artículos en el archivo R que contienen los recursos utilizados por la aplicación (ver también este Descripción general de lo que es el archivo R). Debido a que este archivo se genera automáticamente durante el proceso de creación, no está disponible para el código de prueba. La solución, como se describe en Stack Overflow, es incluir carpetas donde se encuentra el archivo R de forma manual. Este enfoque requiere un “ensamblaje” previo. TENGA EN CUENTA que incluir el archivo R no le da acceso a cadenas u otros recursos que no sean las referencias del archivo R.

Captura de pantalla 2015-07-20 a las 16.19.55

Poniendolo todo junto

A continuación se muestra un ejemplo completo en Gradle:

Captura de pantalla 2015-07-20 a las 4.15.13 p. m.

Para ejecutar y probar por primera vez, realice una de las siguientes acciones:

Captura de pantalla 2015-07-20 a las 4.15.24 p. m.

Para volver a ejecutar las pruebas, realice una de las siguientes acciones:

Captura de pantalla 2015-07-20 a las 4.26.08 p. m.

Los resultados de las pruebas se presentan aquí (en relación con la ruta del proyecto):

Captura de pantalla 2015-07-20 a las 4:15:54 p. m.

Informe de ejemplo a continuación:

Captura de pantalla 2015-07-20 a las 4.16.05 p. m.

Jessica Navarrete

Hola soy la Lic. nutricionista Jessica y eh creado este blog con la finalidad de ayudarte a mejorar tu vida, aqui encontraras consejos, recetas, recomendaciones, entre otras cosas, puede consultarme lo que gustes, estare al pendiente sigue tambien el blog por medio de facebook.

Puede que también te guste...

Deja un comentario

error: Content is protected !!