Preparando nuestro proyecto para pruebas unitarias (TDD)

Parece que hasta ahora hemos dado montones de vueltas antes de empezar a hacer nuestra app, y creanme aun no terminamos, y es que así es más parecido a la realidad.

Hoy vamos a iniciar entendiendo un tema útil y hasta de moda. Como vieron en el anterior post, la estructura de nuestra solución tiene un proyecto de test unitarios y la arquitectura necesaria para poder usarlos. Pues bien antes de eso y para los que no conocen hay que mencionar que es TDD (Test Driven Development)

TDD es una técnica para diseñar software que se centra en tres pilares fundamentales:

• La implementación de las funciones justas que el cliente necesita y no más.
• La minimización del número de defectos que llegan al software en fase de producción.
• La producción de software modular, altamente reutilizable y preparado para el cambio.

Los invito a conocer en detalle sobre el tema con el libro de Carlos Blé, Diseño Ágil con TDD

Ahora bien, hacer TDD no es hacer pruebas como lócos es hacer pruebas con sentido, que ayuden a proteger a nuestro código  de cambios no inápropiados y a estar seguros que al menos cierta parte del mismo funciona correctamente.

Hay que entender que este tema es opcional pero es una buena práctica que vale la pena comentar y aplicar si trabajamos en equipos ágiles. Veamos como lo estamos aplicando en nuestro proyecto de Congreso Visible.

En mi óptica las Vistas Modelo deben quedarse intáctas y no deben tener mocks, los mocks son de fuentes externas o servicios de plataforma especificos tales como settings o caracteristicas del teléfono o tableta, que no estarían disponibles al ejecutar las pruebas unitarias, por esta razón el punto de partida es pensar que tipos de servicios tendremos y por tanto cuales son las interfaces de estos.

Confieso que me demoré más de lo que pensaba montando la estructura de todo esto, la parte positiva es que además de que quedo listo y super desacoplado, ustedes ya lo pueden descargar, verlo y explorarlo. Tenemos solo con un test case inicialmente, pero quedará super listo para ensamblar los demás. Vamos a ver si logro describir las cosas que tuve que hacer.

Lo primero que hice fue definir todas las interfaces de servicios que creo voy a utilizar.

Como ven además definí interfaces para las vistas modelos. Esto pudo perfectamente ser opcional, pero en la idea de intentar desacoplarme de todo fue un buen ejercicio que espero tenga algún proposito más que solo complicarme la implementación, ya que como claramente lo deben intuir las interfaces de las vistas modelos las debe implementar cada una de las vistas modelo que teniamos definidas, por lo que fue necesario trasladar todas las propiedades a las interfaces para que esten disponibles en los test cases y por supuesto realizar la implementación de las propiedades así:

Una interfaz que espero esten notando y se pregunten que es es IBindableServiceLocator. Si recuerdan la el post donde definimos la arquitectura, BindableBase que es quien implementan todas las VistasModelos, tiene un método que recupera del Services Locator, las instancias del servicio a usar. Pues bien, debido a mi uso de interfaces por aquí por allá debemos implementar una interfaz con este método para que así los test unitarios puedan reconocerlo pero recuperando el servicio falso.

Tenga en cuenta por lo tanto que nuestras interfaces de las Vistas Modelo ahora tendrán que implementar tambien IBindableServiceLocator.

Todo esto es un poco pesado al inicio para el esquema mental de quienes apenas están comenzando, pero tengan en mente que algún día lo comprenderán facilmente. Bien, por supuesto espero que sobre decir que además fue necesario crear todos los servicios Fake que probaremos y para eso era el proyecto de FakeServices.

Para entender un poco más por que todas estas complicaciones desde hace ya 5 post, vamos a ver el test case que implementé aquí. Para ello tenemos que conocer la nueva clase TestContainer que implementé dentro del proyecto de test, esto como ensayo no más, en el futuro espero tener varios TestContainer de acuerdo a grupos de pruebas que quiera hacer.

Por el momento, esta clase será la responsable de instanciar las Vistas Modelo y además de registrar los servicios falsos para las pruebas unitarias.

Ahora vamos a realizar la implementación del comando en nuestra Vista Modelo de ejemplo para crear el Test ShareProfile. En este punto está la magía y lo bonito del desacomplamiento, como ven nadie conoce a nadie, solo se usan interfaces. Por lo demás es solo la implementación de un comando, si no lo tienen claro, les recomiento como siempre ver los videos del maestro Josue Yeray explicando MVVM

Por último el lugar donde queríamos llegar es el test case o prueba unitaria. Empecemos por hacer un test que falle. Veamos ¿Por qué falla este test?

Espero que lo hayas adivinado, simple, por que no hay un enlace para compartir, así que al ejecutar los testcase el resultado es...

Usar un contador es una de las estrategias para hacer test, tambien podemos usar Callbacks y de hecho lo veremos en post más adelante pues será la estrategia con la que continuaremos haciendo TDD en nuestro proyecto.

Ahora como manda, hagamos funcionar el test

Y entonces después de todo este trabajo tenemos un bonito "Test case passed!", y la alegría que eso produce es solo apta para geeks! ;)

Si observaron con detenimiento, los mocks los implemento a nivel de Servicios solamente. ¿Por qué entonces hacer interfaces de las vistas modelo? Diría que es un tema de gusto por perseguir el desacople, si analizan o intentan eliminar las interfaces, se darán cuenta que el proyecto de Contratos, quedaría acoplado al de Vistas Modelo y bueno este a su vez estará acoplado al de servicios, así que nó, no es eso lo que persigo :)

Para no perdernos del contexto de nuestra app, aquí les dejo el Modelo de Paquetes actualizado. Sorpréndanse de todo lo que hemos creado y solo es infraestructura.

Entiendo que algunos de ustedes pueden necesitar hacer TestCases sin tener una arquitectura tan elaborada así que no olviden visitar MSDN para saber como ejecutar test incluso cuando los tienen al interior de la app de Windows Phone.

Actualización: He creado un post donde se usa un Test en un proyecto Windows Phone Unit Test para probar la navegación del NavigationService no olviden pasar a verlo, está al final y necesita de lo creado en ese post para ensamblarlo y entenderlo.

Definiendo la arquitectura base de nuestro proyecto

Actualización Febrero 2014: La arquitectura propuesta aquí se refino en el post numero 10 de la serie.

Continuando con nuestro desarrollo, después de pensar un rato en esto, terminé la definición de la distribución de componentes según sus responsabilidades dentro de mi solución. Mi decisión fue no usar controles de terceros y evitar al máximo usar frameworks o librerias externas, con excepcion de SQLite y el Toolkit de Windows Phone, vamos a ver como nos va con esa decisión.

La solución quedó estructurada de la siguiente manera:

Para entender mejor la relación entre los proyectos, les dejo un diagrama de paquetes. Allí se puede observar donde quedaron los modelos que usaremos para consumir los datos vía Json como se explicó en otro post y también las Vistas Modelo que definimos en el post antenior.

* El diagrama está actualizado al 15 de Diciembre con el post 9.

Como ven, el trabajo que tenemos es bastante, aun no se si nos mantedremos así hasta el final, pero lo intentaremos.

Como pueden observar quiero en este ejercicio lograr que la clase de infraestructura sea lo más reutilizable posible, por lo que aprendiendo del mejor maestro Josue Yeray y sus ejemplos, tengo varias clases reusables, incluida una implementación de un Service Locator, que no usa frameworks externos, espero que cuando empecemos la app de Android y iPhone el hecho de no usar más que código C# nos traiga grandes ventanas.

A veces tiendo a exagerar con la separación por assemblies pero les aseguro que estuve pensando en esto un buen rato y por el momento estoy conforme, las librerías todas son portables con este soporte:

Si necesitas conocer que es una Librería Portable (PCL) sus ventajas y limintaciones en MSDN encuentras la explicación en español. Los demás proyectos son una aplicación panorama Windows Phone 8, una aplicación Hub Windows 8, y un proyecto de Test.

No olviden que para entender las decisiones de esta estructura deben tener idea y conceptos al menos básicos de XAML y MVVM razón por la que nuevamente les comparto la diapositiva de intro y no se olviden de ver la explicación en video de Josue Yeray del patrón MVVM.

Ahora, si bien esa es la estructura de nuestra solución, vale la pena detenernos en esas 3 clases en particular de infraestructura, que con suerte son las que nos van a ayudar a trabajar una buena aplicación cross platform, puede que no de la manera más óptima pero si de la más transparente y bajo nuestro control.

La primer clase es BindableBase, tomada tal cual de la plantilla de Windows 8, y adecuada con el Service Locator, es la clase que va a permitir a nuestras Vistas Modelos ser escuchadas por las Vistas cuando realicen un cambio, todo gracias a INotifyPropertyChanged.

La segunda clase interesante es el DelegateCommand en su implementación seguro más sencilla, nos va a permitir enlazar comandos de nuestras Vistas Modelos con nuestras Vistas sin usar Code Behind.

La última pero no menos importante es la clase ServiceLocator que nos permitirá obtener las instancias de las clases que son el contexto de nuestra aplicación desacoplando las vistas de estas clases y a la vez de facilitándonos hacer TestCases pues también tendrá una referencia a los servicios que usamos siempre disponible.

Mi lectura recomendada está en MSDN, aunque no está en contexto de apps móviles de manera general explican el patrón Services Locator.

El Service Locator es una versión especializada del patrón de Inversión de Control (IoC). La inyección de dependencias resuelve el mismo problema que el Service Locator pero usa una implementación diferente, para hacer inyección de dependencias podemos usar componentes como Unity que está disponible vía Nuget para nuestras aplicaciones de forma gratuita y que es provisto por Microsoft Patterns and Practices.

Como ven, las clases descritas cumplen propósitos generales, y si todo sale bien sencillamente podrían ser usadas tal cual en otras aplicaciones.

Actualización 11 de Diciembre: Lo más bonito del conocimiento es cuando se multiplica, les comparto la explicación de Emerson Perdomo sobre Inversion de Control e Inyección de Dependencias. Mil gracias por compartirlo :)

Nota: Veo que este post ha tenido muchas visitas, y no tanto así el de pruebas unitarias, mi invitación es a que se pasen por allá tambien, puesto que al intentar crear las pruebas unitarias para congreso visible, se añadieron más cosas a la arquitectura que deben ser entendidas y tomadas en cuenta.

Actualización 15 de Diciembre: En el post 9 este era nuestro diagrama de dependencias, para entenderlo no pueden olvidar seguir la serie de Congreso Visible para ver de que manera evolucionamos hasta aquí. La parte negativa y a la vez positiva de todo esto es que al hacer este análisis logré identificar que algo estaba mal.

Como pueden ver, el proyecto de insfraestructura tiene una relacion indeseada con Congreso Visible ¿Por qué indeseada? pues bien este proyecto debia ser transportable a otros proyectos sin ser tocado, así que en este punto entre a resolver la situación. Quitando los proyectos de test el nuevo diagrama luce asi:

El cambio interno fue que las interfaces que necesitaban de infraestructura se movieron a ese proyecto y fue bastante transparente, es decir, nuestro proyecto de infraestructura quedaría asi:

* He actualizado el diagrama de paquetes del inicio de este post a la fecha.

Imaginando los prototipos y las vistas modelo

Continuando la construcción de nuestro proyecto de Congreso Visible, después de que conocemos el Modelo de Dominio de nuestro problema a resolver, y por tanto sabemos que información tenemos disponible, podemos empezar a imaginar nuestra app.

En este caso nos ahorramos el tema de colores puesto que la base esta en el sitio de Congreso Visible

Entonces podemos pasar de nuestros no tan lindos Sketchs a un diseño base un poco más apróximado. En este caso para empezar a construir nuestras Vistas Modelo vamos analizar el diseño del panorama de Windows Phone.

Este panorama por ejemplo nos muestra que en nuestro contenedor principal vamos a necesitar al menos 3 listas, una para las personas que seguimos, otra para presentar gente aleatoriamente y otra para la lista de partidos. El buscar más me llevará a otra vista donde usando filtros de búsqueda como en la web podré buscar en la lista total de personas.

Ya que todo los terminos como Vistas, Vistas Modelos y Models, pueden ser un poco confusos para varios de ustedes, pueden pasar por esta ppt antes, al menos para familiarizarse con varios de ellos. Pero no se preocupen, seguiremos haciendo el ejercicio paso a paso.

También les recomiendo revisar la sección de MSDN para Windows Phone, donde de forma muy concreta listan los temas que debes aprender para saber construir apps XAML en Windows Phone.

Pues bien, de acuerdo a lo que tengo en mente al menos inicialmente y según los datos que vi en las respuestas del API esta es la estructura base de mis Vistas Modelo.

Si observan bien no necesariamente tiene la misma estructura de los modelos, y está pensada más bien a cumplir con el proposito de ser el soporte de las vistas claro está. Le faltan algunos datos y seguro, saldrán más durante la construcción, o modificaciones de cosas con las que no me sienta cómoda, les prometo al final hacer ingeniería inversa y ver como quedó.

Mis herramientas recomendadas para hacer los diseños y prototipos estáticos como siempre son:

1. Inkscape herramienta open source para vectores
2. Kuler para paletas de colores
3. The Noun Project para iconos en vectores editables en Inkscape (No olvide el copyleft)
4. UI Stencils para prototipos en papel

Recuerden que hay más recursos para crear prototipos publicados en mi blog y que este tema de construcción de vistas modelos está explicado más ampliamente en este documento que construí alguna vez.

Planificando las bases de una aplicación windows phone from Sorey Garcia

Conociendo el API de nuestro proyecto y construyendo los modelos

Continuando con nuestra serie de post de Congreso Visible, nos encontramos con la idea de bien, ¿Cómo empezar? En nuestro caso lo primero es que nuestro backend ya está listo y es el API pública que nos proveen los chicos de Monoku.

Solo con el ánimo de recordar y para quienes se enten enfrentando a sus propias apps, recuerden, las apps cuando funcionan con datos centralizados son solo un punto de entrada frente al resto del escenario de sus ideas de negocio, aquí un diagrama para recordarles de manera muy general que detrás de sus aplicaciones hay más cosas que considerar.

Para hacerse la vida más fácil y no tener que pensar en toda esa infraestructura que hay detrás, a hoy hay alternativas como Azure Mobile Services, este servicio de Microsoft tiene un límite gratuito y después de tener suficientes usuarios hay que empezar a pagar, pero es una buena manera de empezar, administren la cuota gratuita con inteligencia y preparen pronto sus apps para que puedar dar sostenimiento a los costos que llegan después.

Bien, volviendo a nuestro proyecto, lo primero es conocer la documentación del API si es que la hay. Para Congreso Visible hay un sitio dispuesto para ello y al explorarlo podemos darnos cuenta que tenemos a nuestra disposición un API en formato Json.

Si sabemos como consumir un servicio Json en .NET sabremos también que necesitamos el conjunto de clases que soportan el resultado de cada servicio. Lo que debemos hacer es analizar la estructura de la respuesta, en la web nos enseñan un ejemplo y tambien podemos probar directamente una invocación al API

El análisis de algunos de los datos de muestra del API me dieron la siguiente estructura para contener el resultado de las consultas.

Además logré identificar algunas de las entidades, un par de ellas lastimosamente nunca me trajeron datos pero en cuanto los encuentre actualizo este post.

Como podemos ver es una cuestión de entender el Modelo de Dominio que manejan los servicios y que a su vez serán los modelos que usaremos en nuestra app.

Allí es donde aquellos que apenas esten haciendo sus apps deben hacerse la pregunta de si conocen el Modelo de Dominio que van a construir, y para ello habrá que repasar conceptos de Orientación a Objetos y dedicarle un buen rato a entender lo que quieren construir.

Proyecto OpenSource Windows Phone, Windows 8 y Android

Hola a todos

El día de hoy regreso a postear, llena de energía y esta vez bastante inspirada, hace mucho prometí en este blog explicar sobre MVVM, empecé un tutorial llevándolos por la forma más sencilla de iniciar que era usando la plantilla creada por los panoramas y pivots en Visual Studio, pero justo intentando explicar de una manera simple aquella forma de trabajar me encontré con que implementar MVVM tiene muchas mejoras a eso y alternativas de implementación, además de conceptos de fondo que no me iban a resultar tan fácil de explicarles al público que me dirigía allí.

En algunas ciudades, o mejor paises, los programadores tienen bases conceptuales más fuertes, en otros, diría en mi país, no es tan común que quienes están empezando las tengan en especial Programación Orientada a Objetos, que basicamente es todo lo que se necesita para entender MVVM sea básico o Avanzado.

Así que hoy vuelvo, quizá un poco más abstracta y entendiendo que no puedo llenar en realidad todos los vacíos que tengan respecto a temas como orientación a objetos, arquitectura o patrones, pero con la misma intención de tratar de explicar el resto de una manera lo más comprensible posible y pues que nos enseñe mucho a todos, hasta a mi. :)

Para seguir la serie de post navega la etiqueta de mi blog con nombre Congreso Visible.

Para empezar les contaré, el tutorial está basado en un proyecto muy bonito que conocí de mis amigos de Monoku, se llama Congreso Visible, y busca que la ciudadanía tenga acceso a la información relacionada con las personas que trabajan en el gobierno. Dicho proyecto es mantenido por la Universidad de los Andes de Bogotá y actualmente tiene un API pública que usaremos para realizar las aplicaciones.

Se estarán preguntando por que hablo de hacerla en Android, pues bien esta serie de post incluirá como podemos hacer la misma aplicación para Android usando Xamarin. Aprovecho para agradecer a la gente de Xamarin por mi suscripción de un año a la cual espero sacarle mucho provecho y por supuesto enseñarles a todos ustedes, lo mismo a Telerik por mi suite de controles, cuando termine la app básica espero hacer una versión mejorada usando los controles.

Por el momento les compartiré un par de dibujos de lo que imaginé cuando conocí el API, sujeto está a modificaciones y seguro tambien a recibir todas sus sugerencias. El diseño está enfocado a Windows Phone, ya libraremos el reto de ponerlo en las otras plataformas.

Les comparto mi Mural.ly del proyecto para una inicial lluvia de ideas

Ya que el origen de los datos es público tal como lo comparto en mi post, mi código será abierto y estará publicado en mi Github.

Se reciben correcciones, sugerencias y consejos siempre en buena onda.

Recuerden que como ustedes aprendo cada día y pues de eso se trata esta aventura, además de que juntos multipliquemos el conocimiento y ayudemos a que la comunidad de desarrolladores Windows Phone y Windows 8 siga evolucionando hacia el siguiente paso.

Windows Phone Community Week

Tenía pendiente este post, solo quería decir ¡Gracias!

El Windows Phone Community Week, fue un éxito, gracias a la participación de todos, tanto en el evento oficial como en las charlas adicionales en Campus Party Colombia y sobre todo al apoyo incondicional de mis chicos de Avanet, que se lucieron esta vez. Hicimos parte del evento mundial que se dió durante casi un mes en varias ciudades del mundo, convocando a toda la comunidad de desarrolladores de Windows Phone.

Gracias a Microsoft y a Telerik por que apoyo con los premios y licencias del evento, tan utiles para todos los nuevos devs que inician la aventura de construir apps. Aquí nuestro pequeño y más especial recuerdo

Quisiera compartirles el material de mis dos charlas e invitarlos a visitar el Github de Avanet donde hemos recopilado todo el material de Windows Phone de nuestros eventos.

¡Por cierto! No se olviden además que desde ayer ser desarrollador Windows y Windows Phone es muy fácil y tiene un costo de solo 19 Dolares :), así que sin excusas es el momento de hacer geniales apps.

Tips de Diseño para Desarrolladores

Introducción a XAML y MVVM