¿Por qué hacer Testing?
Al desarrollar Software es probable que no siempre el código que escribas haga exactamente lo que quieres o, algo peor, hace lo que esperas pero “rompe” otra funcionalidad de forma silenciosa sin que te des cuenta.
Por esta razón desde que aprendemos a desarrollar software, cada cierto tiempo ejecutamos el programa y vemos si lo que estamos escribiendo hace lo que nosotros queremos. Esto para mí es hacer Testing. ¿No lo haces?
Puede parecer un tema baladí, pero si realizas las cuentas verás como el tiempo dedicado a esto se come muchas horas del desarrollo. Esto junto a la lectura de código(leemos mucho más código de lo que escribimos al desarrollar cualquier software) son dos aspectos que no solemos valorar. El tema de la lectura se hace palpable cuando leemos libros de referencia como “Clean Code” o “Implementation Patterns”.
El tema del Testing es una cosa que hacemos todos y muchas veces parece que es imposible evitar y estoy de acuerdo, es inviable desarrollar un producto que presente garantías de que funciona bien sin haberlo probado, pero una cosa es hacer el Testing Manual de toda la vida, que tampoco se puede evitar del todo, y otra reducir el tiempo dedicado a él realizando unas pruebas de testing automáticas.
Es tan importante este apartado que ya prácticamente ningún lenguaje de programación puede vivir sin su suite de test. Así nos encontramos con suites para Java (JUnit), PHP (PHPUnit, SimpleTest), Javascript (Jasmine, QUnit), Python (PyUnit), etc.
Todo esto es muy bonito en nuestra cabeza “¡qué bien!, vamos a hacer pruebas automáticas y ya no tendremos que ocuparnos de nada”, pero las pruebas automáticas hay que escribirlas, ejecutarlas y, la parte más importante, mantenerlas. Además el tema de Tests es como el código: cuando más escribes y más estudias sobre él puedes hacer más y mejores cosas pero los principio nunca son fáciles. La realización de tests automáticos requiere experiencia y estudio. Si nunca lo has probado en cuanto empieces notarás que te metes en un mundo nuevo simplemente cuando empieces a leer sobre los tipos de tests que existen. Unitarios, de Integración, de Instrumentalización, de Sistemas, de Aceptación, etc.
Todo esta metodología de entorno de tests ha traído nuevas herramientas y prácticas al mundo del desarrollo de Software. Lo principal sin duda es la tranquilidad del desarrollador como la del cliente. Pero podemos hablar de nuevas formas de trabajo como La Integración Continua (Conitnuous Integration), el Despliegue Continuo (Continuous Deployment) pero esto son cosas que escapan al contenido del post.
Si Android tiene su propia Suite, ¿por qué usar Robolectric?
Efectivamente y sí, Android viene con una Suite para poder testear el desarrollo de una aplicación de manera automática y no es Robolectric. ¿Por qué alguien ha creado Robolectric entonces? La idea es sencilla, durante el desarrollo vamos a querer comprobar si nuestros tests están bien y eso lo haremos muy a menudo, si los tests tardan en ejecutarse segundos tendremos nuestro feedback rápidamente y eso nos gusta, pero si tenemos muchos tests y estos tardan en ejecutarse mucho tiempo puede romper nuestro ritmo de trabajo, que perdamos el foco sobre lo que estamos trabajando o cualquier otro aspecto negativo derivado de las esperas.
La Suite de Android está muy bien trabajada, pero tiene el “fallo” que debe ejecutarse en un terminal físico o en un emulador y esto hace que los test no sean tan rápidos como nos gustarían.
Os dejo un vídeo sobre una presentación de Robolectric, antes de empezar a hablar sobre Robolectric hay una introducción de unos 10 minutos donde nos muestran como implementar los tests con la Suite que viene con Android, está en inglés pero espero que muchos de los que pasen por aquí puedan disfrutarlo. El video en sí durante unos 40 minutos.
Lo que viene a decir es que Robolectric es una Suite para Android que ejecuta los tests sin pasar por terminal físico o emulador por lo que puedes realizar un número mayor de tests en menos tiempo. El video tiene un par de años y hay versiones evolucionadas de las librerías pero el concepto sigue siendo muy parecido hoy en día.
Preparar el entorno
En la empresa (Kinética), nos dimos cuenta de la importancia de realizar tests, pero no los hemos metido directamente en todos nuestros proyectos sino que estamos adecuando nuestros desarrollos para que cada vez tengan más tests automatizados.
Por ser el desarrollador de Android me he encargado de investigar este apartado y hacer un mínimo de pruebas para asegurarnos de que la Suite que usemos nos de un valor añadido.
Las primeras pruebas han consistido en montar diferentes entornos de trabajo que nos permitan/ayuden a realizar estas prácticas, hasta el momento desconocía el mundo de Maven así que he preparado el entorno de dos formas con y sin Maven. He querido transmitir la experiencia a través de unos vídeos y he aquí el resultado.
Eclipse sin Maven
Android Studio con Maven
Tras la experiencia creo que optaremos por la opción con Maven, tiene varios contras: nos obliga a conocer una herramienta nueva y presumiblemente va a ser sustituida por Gradle, aún así creo que nos puede ayudar a afianzar conceptos y metodologías que serán serán extrapolables a Gradle. Aparte creo que por ahora seguiremos trabajando con Eclipse hasta que Android Studio evolucione o nos acostumbremos.
¿Sólo nos muestras como montar el entorno?
Creo que hasta aquí es una buena introducción al tema de Testing para Android con Robolectric para alguien que esté empezando como es mi caso, espero seguir profundizando y pudiendo redactar más posts como este relatando mi aventura ya sea añadiendo experiencia con Robolectric o con otras herramientas que ayuden a facilitar la tarea del desarrollador de software.
No comments:
Post a Comment