Code Coverage para Identificar Casos de Pruebas Importantes

Esta herramienta es muy útil. Nos ayuda a ver que porcentaje de nuestro código esta realmente siendo ejecutado. Hay código que nunca se toca y esto nos puede indicar tres cosas.

1. Es código que realmente no se usa y sólo estorba y perjudica a la mantenibilidad de nuestro proyecto. Solución: Borralo.

2. Es código que no se está probando. Solución: Crea una nueva prueba.

3. El código es tan simple que no hace falta probarlo. Esto pudiera ser real, sin embargo, si en todo el set de pruebas no se pasa nunca por ahí nos hace pensar que tal vez nunca se usa en toda la aplicación.

El punto uno es simple, solo no le agarren cariño al código que no sirve y presionen delete sin llorar por las horas que invirtieron en algo que nadie usara. El punto dos se puede cumplir de muchas formas, la ideal es una prueba unitaria que podamos repetir constantemente, sin embargo, podríamos hacer un WebTest o Manual Test, lo importante es que se pruebe.

Podemos ver un ejmplo reciente.

En este caso vemos que nuestro metodo Borrar Artículo siempre se esta probando cuando el baseNode no tiene un artículo. Esto pudiera no ser muy critíco porque los otros tres metodos si estan cubiertos por otras pruebas, sin embargo, es una prueba básica que debería estar considerada.

No es necesario llevar esta practica a un extremo y querer tener 100% Code Coverage, en muchos proyectos no vale la pena, sobre todo con código heredado o si no se inicio con buenas prácitcas. Lo que si debemos tener bien presente es que no baje nuestro code coverage, es decir, iteración tras iteración o mejor aún (Si usan Integración Continua) check-in tras check-in  nuestro porcentaje de cobertura aumente, esta es una buena metrica para el equipo completo. 

Links

Como Configurar Code Coverage en Team System (MSDN)
Configurar Integración Continua en Team System 2005
Configurar Integración Continua en Team System 2008
Code Coverage para NCover (Si pruebas con NUnit)

Technorati Tags: Code Coverage,Team Foundation,TDD,Metodologías Ágiles,Visual Studio 2008

Updated MEDC 2006 Hands On Labs for Mobile Client Software Factroy

Here's the update.

The original HOL was designed for drop 12 of the MCSF and there were some namespace chages by the final version. All projects should be working by now, we have used them several times.

This version targets VS05, if you open it on VS08 consider the following:

• You wont be able to use the guidance and do HOL 4 for Orientation Aware.
• When prompted to update just leave the projects in .NET 2.0 (there is no easy way to change that back if you upgrade them to 3.5).
• You will need to replace the dlls in dlls/MobileSoftwareFactory with the ones in dlls/MobileSoftwareFactory08. The main difference is now Mobile.DataAccess.dll uses SqlServer CE 3.5 instead of 3.0.3600.0. This is important, even tough it compiles you will have troubles at runtime.
• Sometimes you might need to upgrade the sdf file manually.

Next month we will be releasing on CodePlex an updated version of MCSF that works with VS08, except for OrientationAwareControl. Clarious Consulting is planning an update for their OAC which you could use instead.

I didn't write the HOLs, I'm just making the update we used internally available, anyway, if you have some trouble it might be something we already ran into, so please leave a post on the Mobile Blocks at Codeplex or leave me a message here.

Web Development Helper y Otras Herramientas para Desarrollo Web

El Web Development Helper es una herramienta muy útil cuando se desarrolla en ASP.NET. En este caso nos muestra con el Http Logging habilitado todos los requests que esta haciendo Interent Explorer, esto nos puede ser muy útil como por ejemplo en este caso para saber porque no estaba cargando el Xaml de una aplicación de Silverlight. Un error muy menso obviamente, pero detactado rápidamente con la herramienta, pudieron haber sido muchas otras cosas, un script que cargaba no cargaba bien el Xaml.

Adicional al HttpLogging, se integra bastante bien con ASP.NET de tal forma que desde ahí pudieramos ver el ViewState, Cache, Trace, tiene una consola de Script para escribir, un DOM Inspector entre otras cosillas interesantes. Puedes descargarlo desde aquí.

Otras herramientas básicas para el desarrollo en Web son:

Fiddler: monitorea el puerto 80.
IE Developer Toolbar: nos permite ver como Internet Explorer esta rendereando nuestra página seleccionando elementos en ella y explorando el DOM.
BugZilla: add-in para Firebird con excelentes características para depuración.
ScriptSharp: compilador de C# a JavaScript, el logging para JavaScript es muy útil.
Visual Studio 2008: con soporte mejorado para manejo de hojas de estilo y depuración e intellisense para JavaScript.
Aptana: IDE basado en Eclipse que con mejor soporte para depuración e intellisense para JavaScript (también sirve para Ruby).

Seguramente se me pasan algunas que no utilizo tan frecuentemente. Lo importante de estas herramientas es saber que hacen y tenerlas presentes para saber cuando usaralas.

Aspect Oriented Programming Aplicado - PostSharp, Logging y HttpSimulator

Siempre me había intrigado por AOP y es que la idea de programar basado en aspectos en lugar de funciones o metodos o código secuencial es bastante atractiva. Obviamente no es para todo código, pero hay muchos "aspectos" que quisieramos poder tener encapsuladas y no sólo en un objeto, sino, despreocuparnos y no tener que invocarlas nosotros mismos.

Ejemplo Simple - Logging.

Pensemos que queremos loggear excepciones.

Ok, ese el código feo de novato. Ahora refactoricemos un poco. Podría estar en una clase y para cuestiones de la prueba hagamosla estática.

Ahora apliquen eso a todos los metodos de la clase. ¿Qué? Bueno supongan que nos interese enterarnos en nuestro archivo de Log de todos los lugares donde lleguue a ocurrir una excepción. Vamos a convertir esto en un aspecto. Refactoricemos de nuevo.

Simplemente hicimos nuestra clase serializable (necesario por PostSharp), hereda de OnExceptionAspect, overrideamos el Metodo OnException y listo, Logueamos tal como antes.

Ahora simplemente decoramos nuesto metodo con nuestro nuevo atributo, corremos la app y listo. El atributo también podría ir en una clase y aplicarle algunos filtros. Estas son sólo algunas de las posibilidades.

Puedes descargar el código aquí

Por mantener breve el ejemplo, la clase loggin es muy simple, en una aplicación real sugeriría usar el Loggin Application Block que es parte del Enterprise Library o Log4Net, ambos son open source y podrían integrarse con PostSharp.

Para un ejemplo aún más simple que este, vean el Video de Intro de PostSharp. El ejemplo me parecio poco práctico, sin embargo, es muy ilustrativo respecto a como usar la herramienta y sólo dura 5 minutos. Pueden bajar el código del video aquí.

Otro Ejemplo Simple - HttpSimulator

Hace algún tiempo escribi respecto al HttpSimulator, desde entonces lo hemos tenido que usar muchas veces para simular el contexto de Http en clases que dependen de algun objeto de ASP.NET y queremos probarla sin necesidad de que tenga dependencias a los objetos reales del framework, es decir, no queremos tener que usar realmente sesión y pasar por todo el pipeline de un request web, sólo para probar un simple metodo.

En el código a descargar viene todo el HttpContext, ahorita nos enfocaremos a las pruebas unitarias, estilo TDD para el HttpContext y como usarlo con PostSharp, en la prueba usaremos un WebDependentClass

Eso esperamos que arroje una excepcion, ya que WebDependentClass se debería ejecutar en un contexto web para que pueda usar HttpContext.Current tal como se muestra.

Ahora veamos como se haría esto con el HttpSimulator para lo que creamos otra prueba.

Es simple, se obtiene el path, se crea la instancia, se empieza a simular el request, se hace lo que se tenga que hacer y al salir del using se ejecuta el dispose y termina la simulación. Nuestra prueba pasa y todos contentos. Sólo que es mucha talacha. Puede haber 126 pruebas más que usen el Simulator. Aunque se podría simplificar un poco la creación, terminaríamos aún así con código repetido y el using no tenemos manera de evitarlo.

Con AOP, tenemos algo como lo siguiente:

El atributo se encarga de todo, inclusive si todas las pruebas de nuestro TestClass o nuestro Assembly de pruebas necesitaran del simulador podríamos definir el atributo a nivel de clase o assembly para aplicarles el mismo aspecto.

La implementación del atributo es de lo más simple. Tal como hicimos con el Logging, tenemos la clase serializable y hereda de un atributo predefinido en PostSharp.

Parece un Surround with snippet no? Es similar sólo que para tiempo de compilación.

Si quieres usarlo en tus pruebas, simplemente agrega el Assembly HttpSimulator y el atributo a las que dependan de un contexto Http. Puedes bajar el código de aquí.

Links

Downloads

SuperSimpleSample
LoggingSample
Attribute para el HttpContextSimulator
Todos los samples de este post
PostSharp Installer

PostSharp

PostSharp en .NET Rocks
PostSharp
Video de Intro de PostSharp

HttpSimulator

Post viejo mio
HttpSimulator

Miguel Madero

Net CF Loader Log nos ayuda a depurar aplicaciones.

Tenemos todo bien configurado, nuestros ambientes de prueba, servidor de integración continua, pruebas unitarias, hacemos pruebas de usabilidad, integración, etc, pero siempre estamos expuestos a que se nos escape algún bug. Escribi hace algún tiempo respecto a como tratar los bugs, a veces hay que tomar medidas alternas.

Los bugs más difíciles son aquellos que tienen que ver con cuestiones externas a tu aplicación, el sistema operativo, el explorador que usa tu cliente, cuestiones externas difíciles de reproducir como tipos de conexión (celular, wi-fi, etc), etc. Todo esto la mayoría de las veces termina siendo alguna babosada.

Esta es la historía. Como siempre, todo funciona bien en nuestro entorno de pruebas, se crea el installer, se distribuye usando UpdaterAgent (como ClickOnce para Mobile) y en algunas agendas funciona la app y en otras no.

Primer paso revisamos el log de errores.

----------------------
Version: 3.0.2933.38083
17/01/08 11:33:57 a.m.
Cerrando la aplicación. Error inesperado: InvalidProgramException
-----------------------
-----------------------
Version: 3.0.2933.38083
17/01/08 11:33:58 a.m.
System.InvalidProgramException: InvalidProgramException
en System.RuntimeType.InternalGetConstructors()
en System.RuntimeType.GetConstructors()
en Microsoft.Practices.Mobile.ObjectBuilder.ConstructorReflectionStrategy.GetMembers()
en Microsoft.Practices.Mobile.ObjectBuilder.ReflectionStrategy`1.BuildUp()
en Microsoft.Practices.Mobile.ObjectBuilder.BuilderStrategy.BuildUp()
en Microsoft.Practices.Mobile.ObjectBuilder.PolicyProviderStrategy.BuildUp()
en Microsoft.Practices.Mobile.ObjectBuilder.BuilderStrategy.BuildUp()
en Microsoft.Practices.Mobile.ObjectBuilder.SingletonStrategy.BuildUp()
en Microsoft.Practices.Mobile.ObjectBuilder.BuilderStrategy.BuildUp()
en Microsoft.Practices.Mobile.ObjectBuilder.TypeMappingStrategy.BuildUp()
en Microsoft.Practices.Mobile.ObjectBuilder.BuilderBase`1.DoBuildUp()
en Microsoft.Practices.Mobile.ObjectBuilder.BuilderBase`1.BuildUp()
en Microsoft.Practices.Mobile.CompositeUI.Collections.ManagedObjectCollection`1.BuildFirstTimeItem()
en Microsoft.Practices.Mobile.CompositeUI.Collections.ManagedObjectCollection`1.Build()
en Microsoft.Practices.Mobile.CompositeUI.Collections.ManagedObjectCollection`1.AddNew()
en Microsoft.Practices.Mobile.CompositeUI.Common.ControlledWorkItem`1.OnBuiltUp()
(más y más llamadas)

Nuestro stack es tan grande que ni sentido tiene reproducirlo. Pero hasta ahí es la parte importante. Tenemos un InvalidProgramException que no nos dice mucho. Lo más cerca que podemos llegar es hasta el Código de ConstructorReflectionStrategy.GetMembers, el resto es el framework. Vamos a depurar y encontramos que el error esta al querer obtener los constructores de una de nuestras clases, vamos y revisamos que ahí no este el problema. Tiene un constructor publico que no recibe parametros al igual que las clases de las que hereda, tal como sospechabamos el problema no es esa clase.

Vamos a ver que hay de partícular en las agendas que fallan. Empezamos por crear una prueba unitaria que no haga más que usar directamente reflecto para obtener los constructores de esa misma clase. Se prueba en el emulador y todo funciona, se prueba en una de las agendas que falla y falla. Excelente, ya aislamos el problema. ¿Y ahora? Seguimos sin saber el porque del error, sólo que truena al tratar de obtener los constructores. Seguramente es un problema en como se cargan los objetos y ahí entra el Loader Log.

Se empieza por activar usando el Net CF Logging Configuration que es parte de los .NET Compact Framework Powertoys para 3.5.

Siguiente paso, correr nuestra aplicación en un dispositivo que si funciona y copiar a nuestra maquina el archivo de log "netcf_Loader.log". Luego hay que hacer lo mismo en una agenda que no funcione. El log es muy fácil de interpretar y Steve Prtachner ya lo describio a detalle, así que no lo haré ahora, pero para lo que queríamos encontrar de diferencia ni siquiera necesitamos tanta información.

Con los dos archivos en nuestra máquina usamos Beyond Compare o alguna herramienta similar y vemos las diferencias.

Al principio todo es igual, salvo cosas no importantes como el ProcessID. La secuencia y que busca y resuelve cada referencia es identica hasta que llegamos al punto donde truena.

Vemos que después de cargar el Modulo ConnectionMonitor, trata de cargar el de SqlServerCE 3.5 en el log de la agenda que si funciona, sin embargo, la secuencia es muy distinta en las otras y trata de cargar aún la versión anterior del SqlCE.

Listo, problema resuelto, resulta que el GetConstructors, para obtener los members de esa clase carga los modulos hacía los que tiene dependencias, uno de esos es SqlServerCE 3.5 y no estaba bien instalado en la agenda.

En este momento podrías estar pensando, porque diablos no revisandon la instalación de todo antes de continuar, claramente era un problema de instalación. Claro que podríamos haber hecho un checklist y revisar que todo estuviera bien, sin embargo, no hicimos eso y tuvimos que darnos cuenta de una manera distinta, pero esa es otra lección aprendida y no la del tema de este blog. Por eso les decía que este tipo de problemas muchas veces termina siendo una babosada.

El Loader Log nunca me había resuelto nada, aunque lo había usado un par de veces sin ningún éxito. Lo importante de esta y tantas herramientas, de las que escribire más adelante es el conocerlas y saber que estan ahí instaladas en la máquina para que algún día, tal vez después de algunos años la uses y te saquen de algún problema. Esa es la lección del día.

Siempre he considerado a prodigy como la única alternativa de Internet para negocios y esto ha sido especialmente porque otros proveedores tienen puertos bloqueados y el tipo de red que ellos utilizan no permite muchas de las actividades necesarias para una empresa. Por otro lado, considero que han tenido un buen soporte al cliente y una buena comunicación.

Todo esto ha cambiado recientemente, con “La protección del puerto 25”. Entiendo que es una medida necesaria debido al SPAM, sin embargo, para todo negocio es indispensable el envío de e-mails utilizando las cuentas de la compañía. Obviamente la situación no es tan crítica como para no poder mandar correos jamás, hay varias alternativas (desde usar Webmail, hasta solicitar que eliminen la protección para tu cuenta. Más información). El problema radica realmente en la falta de comunicación de esta empresa hacía sus clientes.

Mes a mes mandan publicidad y todo tipo de información junto con el recibo, tienen nuestros e-mails alternos al momento de que creamos una cuenta para pagarles el recibo y, vamos, se trata de una empresa de comunicación que no debería tener problema en contactarnos para avisarnos de sus nuevas políticas que van a afectarnos.

Su respuesta es, les avisamos enviando un correo a un cuenta de prodigy. ¿Saben lo ridículo que es esto? Si esto sólo nos va a afectar a los que usamos una cuenta distinta como nos escriben a esa dirección, ellos mismos dicen: “La protección del puerto 25 no afectará a aquellos usuarios que estén utilizando los servidores SMTP de TELMEX, es decir, esto no afectará a usuarios TELMEX con cuentas @prodigy.net.mx”. Así cuando cambien mi mis políticas de venta para mis clientes de Alemanía le voy a mandar una carta a todos mis clientes en Italia a ver si aquellos de Alemania se enteran y para que les de más coraje les voy a comentar, “su sucursal de Italia debería haber recibido una notificación”, “ahhh no tiene sucursal en Italia?, debería tener una”. Todavía me dicen, debería checar su cuenta de prodigy.

Bueno en si la forma de resolverlo a rápida y sencilla, la medida es buena, pero para un negocio durar un día o más sin poder enviar mails es algo critico y parece que a Telmex no le importa mucho esto.

Aún cuando le digo a la persona de soporte, “me parece absurdo que el medio de avisarme sea mandándome un mail a prodigy, sólo se lo digo como retroalimentación y me gustaría que lo tomaran en cuenta para futuros avisos”, su respuesta fue, “no me parece absurdo y es el primer cliente que me lo dice”. Así que por favor compartan y expresen su odio.

Les dejo el link de un post de alguien que parece odiarlos más que yo en este momento.

http://www.malditoweekend.com/telmex-bloquea-puerto-25-smtp/

Y un link de gente medio desorientada.

http://www.matuk.com/forosmatuk/?forum=3&topic=212&page=2

Esta es la liga para desbloquear el puerto, úsenla.

https://www.beneficios.telmex.com/puerto25Prod/iniciaPuerto25Internet.do

Por cierto, si no han pasado por esto aún es porque no reinician aún su modem, ayer se fue la luz por la noche y al día siguiente no más SMTP. Llenen el formulario de una vez ya que al parecer toma un tiempo para que lo desbloqueen. Si este post se publica significa que ya lo hicieron ya que estoy publicándolo desde Outlook. Llene el formulario a las 8:40 pm del día 7 de Enero y tomo hasta la hora de publicación de este post.

Miguel A. Madero Reyes
Integradores Tecnológicos S.C.
www.integradorestecnologicos.com
www.miguelmadero.com (blog)