TDD, Unit Testing y Code Coverage

Todo desarrollo de software que se precie debería realizarse según las directrices del TDD (Test Driven Development) o Desarrollo Orientado a Pruebas, ya que nos va a permitir crear un código más mantenible y escalable.

Esto no es algo nuevo, al contrario, y la verdad es que está bastante trillado, pero siempre es bueno recordarlo ya que lo considero una de las mejores prácticas para el desarrollo de software.

Las pruebas unitarias son, más que útiles, fundamentales ya que nos permiten trabajar de una forma desacoplada y nos ayudan a estructurar y encapsular nuestro código. Pero una vez que las tenemos en verde, ¿Cómo podemos saber qué es lo que se está probando y si están bien hechas?

Aquí es donde entra el Code Coverage.

El code coverage como medida de calidad de nuestras pruebas unitarias, por lo tanto de nuestro software.

El Code Coverage, es una medida que nos va a permitir conocer el porcentaje de ejecución de nuestro código, tras haber ejecutado una batería de pruebas.

De esta medida, podemos sacar varias conclusiones:

1. Podemos necesitar más pruebas unitarias.
2. Hay código que hemos creado, que nunca se va a ejecutar, por lo tanto no es necesario y sobra.

El Code Coverage, no es necesario que este al 100%, ya que para conseguir esto, quizás tengamos que realizar pruebas unitarias que realmente no sean tales o no sean muy útiles (por ejemplo que estemos probando el Framework en lugar nuestro código), pero sí que es verdad que cuanto más cercano sea al 100% mejor.

La buena práctica, es trabajar con pruebas unitarias, y usar el code coverage como métrica de la calidad de nuestro software y eficacia de nuestro equipo, ya que lo interesante es ver como el code coverage va creciendo (o por lo menos va manteniéndose) iteración tras iteración en el ciclo de vida del desarrollo el software.

Y para finalizar, deciros, que hay varias herramientas por ahí, aunque yo la verdad, solo he usado la que viene con Visual Studio 2008.

Para activar el Code Coverage, únicamente tenéis que ir a:

Test -> Edit Test Run Configuration -> Local Test Run

Y en el dialogo que aparece, vamos a la pestaña de Code Coverage y elegimos los proyectos a los que se lo queremos aplicar.

Aqui teneis una captura del Code Coverage de uno de los proyectos que hemos acabado recientemente, aunque no se vea el porcentaje total (por no desvelar el proyecto que es), ha sido un 91%.

Code Coverage en el ultimo proyecto en el que he estado

Nada más por hoy mis druguitos. Os dejo que tengo que estudiar, pero no os quedais solos, aqui teneis a The Pains of Being Pure At Heart que son geniales y me ponen mogollon.

Anuncio publicitario

Los métodos extensores.

Los métodos extensores, nos permiten “extender” la funcionalidad de una clase sin que sea necesario usar herencia o polimorfismo pudiendo añadirle funcionalidad a clases “core” del Framework.

Hay que tener en cuenta, que estos métodos aunque son muy útiles, en ningún caso pueden sustituir a la herencia de clases.

Para crear un método extensor, necesitamos un código tal como el siguiente:

public static string ToMD5(this string str)
{
MD5 md5 = MD5CryptoServiceProvider.Create();
ASCIIEncoding encoding = new ASCIIEncoding();
byte[] stream = null;
StringBuilder sb = new StringBuilder();
stream = md5.ComputeHash(encoding.GetBytes(str));
for (int i = 0; i < stream.Length; i++) sb.AppendFormat("{0:x2}", stream[i]);
return sb.ToString();
}

Como veis, el metodo extensor, ha de ser estático y ademas, va a recibir siempre como parametro el objeto que lo llama, a este objeto tenemos que añadirle el parametro this.

Así de facil y sencillo. Este tipo de metodos, los había usado con JavaScript y ActionScript, y ahora, mis drugitos, los podemos usar con C#, toda una maravilla.

Bajate el código y échale un ojo, y cuando uses este tipo de metodos, cuidado, ten en cuenta que no estan pensandos para sustituir la funcionalidad que nos proporciona la herencia, y como bien dicen aquí, es interesante agruparlos en un mismo namespace (que en una única clase).

Nunca han sido santos de mi devoción los planetas, aunque desde hace unos días, no paro de escuchar su “corrientes circulares en el tiempo”, canción mucho más madura que la mayoría de sus exitos.

Silverlight, estilos y el atributo BasedOn.

Tras los bucólicos días que he pasado al sur del Moncayo vuelve el hombre, no tan descansado como debería pero menos es nada.

Como ya hemos visto en otros post, me encuentro (el 20% de mi jornada laboral) en un proceso de aprendizaje de Silverlight. Tras leer algunos libros sobre el tema, comencé a desarrollar BookLight (;-) codename de una app que gestiona la biblioteca de la empresa) y gracias a esta app, me estoy encontrando con cosas interesantes y otras no tan interesantes.

Una de esas cosas, son los estilos.

Silverlight, nos permite generar una “suite” de estilos que posteriormente podemos ir asignando a los distintos controles de manera que en el momento que modificamos estos estilos, actualiza el aspecto de todos los controles que los “consumen”.

Estos estilos no son exactamente iguales a los (geniales) cas, aunque algo tienen en común. Definen el aspecto del control y en Silverlight (y dpb) pueden definir parte del comportamiento del control, tal como animaciones.

Cuando trabajamos con Blend y nos disponemos a crear estos estilos, nos da la posibilidad de crear el estilo de forma “global” (guardándolo en el app.xaml) o de forma “local” añadiéndolo al propio documento. Estos estilos pueden heredar de otros, y además es sumamente sencillo hacer esto, solo que en Blend no es muy aparente (si os digo la verdad yo no he encontrado la forma, lo cual puede ser normal por otra parte).

Para heredar unos estilos de otros vamos a usar el atributo BasedOn por medio del cual indicaremos cual es el estilo padre. Podeís ver su uso aquí:

<Style x:Name="BaseText" TargetType="TextBlock">
<Setter Property="FontFamily" Value="./../Fonts/Fonts.zip#Arial" />
<Setter Property="TextWrapping" Value="Wrap" />
<Setter Property="FontWeight" Value="normal" />
</Style>
<Style x:Name="BookLight.BookingBook.Title" TargetType="TextBlock" BasedOn="{StaticResource BaseText}" >
<Setter Property="FontSize" Value="28" />
<Setter Property="Margin" Value="10, 10, 10, 10" />
</Style>
<Style x:Name="BookLight.BookingBook.Title.Success" TargetType="TextBlock" BasedOn="{StaticResource BookLight.BookingBook.Title}" >
<Setter Property="Foreground" Value="#FF66CC00" />
</Style>
<Style x:Name="BookLight.BookingBook.Title.Error" TargetType="TextBlock" BasedOn="{StaticResource BookLight.BookingBook.Title}" >
<Setter Property="Foreground" Value="#FFFF6600" />
</Style>

Y esto es todo. Se despide vuestro amable y querido narrador no sin antes hablaros de The Phenomenal Handclap Band formada por gente de The Jon Spencer Blues Explosion y Mooney Suzuki.

Expression Blend y las excepciones en tiempo de diseño. Excepción: Argument Null Exception. Value cannot be null.

Ahora que me encuentro en pleno aprendizaje de Silverlight y su editor gráfico, es decir Expression Blend, me estoy enfrentando a un mundo nuevo (aunque realmente no sea tan nuevo) con muchas cosas por ver y aprender.

Una de las cosas que me ha sorprendido a la hora de desarrollar con Visual Studio – Blend, es la dualidad que aparece ahora, y de la cual nos podemos beneficiar a la hora de crear las interfaces de usuario que consideremos pertinente. Que exista esta dualidad y podemos trabajamos con el xaml desde diferentes entornos es beneficioso, ya que así cada uno puede decidir cuál es el entorno que más le satisface para crear unas tareas x, por lo tanto, trabajamos más a gusto y a la larga es mejor.

Eso sí, al existir esta dualidad de “ides”, nos vamos a encontrar con casos un poquito peculiares, por ejemplo, el que hoy nos trae aquí.

Para aprender una nueva tecnología, no hay nada como verse inmerso en un proyecto, donde tengas unos tiempos que cumplir, una funcionalidad que realizar con una calidad x, tengas que trabajar con distintas tecnologías simultáneamente, implementar n patrones  etc. Así pues, revise las aplicaciones que tenemos (en la compañía donde trabajo), y decidí que una aplicación interesante para realizar con silverlight, sería la biblioteca (app que gestiona la adquisición y préstamo de libros teckies), ya que hay que acceder a una db para coger la información, tratar esta información etc. y además le daba una vuelta a una app que hacía años nadie tocaba.

Tras decidir que el codename de la aplicación sería Booklight, comencé a diseñar la interfaz. Tras hacer un diseño (grafico y de interacción) con Fireworks (no lo hice con Blend porque no hay que olvidarse de que el propósito de este desarrollo era aprender) y pensar en cómo podía orientar la arquitectura de esta aplicación, abrí Blend y comencé a plasmar el diseño realizado con Fireworks en Expression Blend. Realice la interfaz y empecé a codificar el asunto, llamadas a servicios wcf, acceso a base de datos, implementación model view viewmodel (del que hablaremos en su momento) y llego un momento que al abrir mi Expression Blend, me encontraba con un error que decía algo así como:

Argument Null Exception: Value cannot be null.
Parameter name:stream

Argument null exception. Value cannot be null.

Me resulto muy curioso, ya que yo podía hacer un rebuild en Visual Studio y todo estaba ok, pero en Blend seguía el error.

Tras buscar un tiempo en google, descubrí que en tiempo de diseño, se pueden producir excepciones.

En mi caso, en el constructor de una clase, estaba haciendo una llamada asíncrona a un servicio, y como es natural, Blend, no podía ejecutar la llamada.

Para solucionarlo, tan sencillo como comprobar si nuestro cliente rico, está hospedado en un navegador.

El código necesario para esto, el siguiente:

HtmlPage.IsEnabled

Con esta pequeña funcionalidad, evitaremos este tipo de errores y algún que otro quebradero de cabeza, y cuando abramos nuestro Blend, lo que veremos sera lo que hay que ver, en mi caso, aqui teneís:

interfaz en la que hay que trabajar

Ahora quizá deberíamos debatir sobre si Expression Blend tiene que mostrar excepciones o no, pero creo que será en otro momento, aunque os adelante que a mi parecer, Blend debería dedicarse únicamente a ayudarnos a plasmar toda nuestra creatividad en un medio digital. En Flash (durante 2 años desarrolle con Action Script), esto está mejor resuelto, aunque también es verdad que el tratamiento de excepciones de flash (yo me quede en Flash 2.0, cuando comenzaron a orientarlo a objetos) era un poquito pobre.

Nada más amigos, es Agosto y debería estar de vacaciones y la verdad no se qué hago aquí. De momento, vamos con los más grandes del 2 tone.

Creando secciones de configuración personalizadas con ConfigurationSection. Como mejorar y organizar los ficheros de configuración y los deployments.

Organizar los web.config o app.config, es una tarea que debería estar presente en cualquier ciclo de desarrollo de software. Lamentablemente no siempre se realizan estas tareas, ya que el Framework de ASP.NET, nos facilita una serie de mecanismos para que de una forma muy sencilla, podamos acceder y almacenar la configuración que necesitemos en un momento x.

Anteriormente hemos visto como usando ficheros de settings, podemos organizar nuestro web.config de una forma muy eficiente y sencilla, ahora vamos a ver algo un poquito más avanzado, pero igual de fácil.

.Net, a través de su Framework (desde la versión 2.0), nos facilita una serie de clases que nos permiten personalizar los ficheros de configuración en función de nuestras necesidades, permitiéndonos crear nuestras propias secciones dentro de la configuración de manera que el web.config o app.config nos va a quedar mucho más organizado y consolidado.

Así pues si estas cansado de almacenar la configuración de tu aplicación como una lista interminable de entradas en el nodo appSettings y quieres organizarlo un poquito, continua leyendo y vamos al asunto.

Creando la clase que encapsula el acceso a nuestra sección personalizada dentro de la configuración.

Lo primero que vamos a hacer es crear la clase que nos va a permitir encapsular el acceso a nuestra sección personalizada. Esta clase debe heredar de la clase ConfigurationSection del Framework y posteriormente vamos a ir creando una propiedad por cada ítem que se vaya a almacenar en la configuración.

La clase puede ser algo así:

public class BlogSettings : ConfigurationSection
{
}

Ahora nos toca crear las propiedades que nos encapsulen el acceso, vamos a ello:

[ConfigurationProperty(TITLE_PROPERTY_NAME, DefaultValue="A deshoras", IsRequired=true)]
public string Title
{
get
{
return (string)this[TITLE_PROPERTY_NAME];
}
}

Como veis, estas propiedades están marcadas como ConfigurationProperty, y además, le indicamos el nombre de la propiedad dentro de la configuración, el valor por defecto y si es requerida o no.

Creando un Manager que gestione nuestra clase de configuración.

Como queremos que esto quede de maravilla, vamos a crear un manager, este se tiene que encargar de automatizar el acceso a la sección de configuración personalizada (custom configuration section) y la modificación si es preciso.

Para realizar estas funciones, vamos a crear una clase estática, que como miembro, tendrá una instancia de la clase que anteriormente hemos creado.

El manager, será algo así:

public static class BlogSettingsManager
{
#region constants
private static string BLOG_SETTINGS_NODE_NAME = "BlogSettings";
#endregion
#region members
private static BlogSettings _settings = ConfigurationManager.GetSection(BLOG_SETTINGS_NODE_NAME) as BlogSettings;
#endregion
#region Properties
public static BlogSettings Settings
{
get { return _settings; }
}
#endregion
}

Creando nuestra sección personalizada (custom configuration section) dentro del web.config o app.config.

Y ya solo nos queda añadir nuestra sección personaliza al web.config o app.config. Para ello, tenemos que añadir un nodo section hijo del nodo configSections, y en este nodo, tenemos que indicar el nombre de nuestra sección, y el tipo, que no viene a ser otra cosa que el nombre de la clase con el namespace y el nombre de la dll donde tengamos la clase que va a gestionar esta configuración (en nuestro caso BlogSettings).

El código sería el siguiente:

<configuration>
<configSections>
<section name="BlogSettings" type="CustomConfigurationSection.Framework.BlogSettings, CustomConfigurationSection.Framework"/>
</configSections>
<BlogSettings Title="Adeshoras" NumberOfItemsPerPage="20" />
</configuration>

Ahora solo nos queda usarlo a lo largo de nuestra app, y esto amigos míos, es lo más sencillo de todo, sería un código del estilo al siguiente:

BlogSettingsManager.Settings.Title

Como siempre, te recomiendo que te bajes este código y lo veas en vivo y en directo, seguro que te maravilla.

Nada más, como podéis ver mis druguitos, de una forma muy sencilla podemos encapsular el acceso a nuestra configuración y además personalizar los ficheros donde almacenamos la susodicha configuración (en nuestro caso web.config o app.config). Esto es muy simple y elegante y con una funcionalidad de este tipo, los deployments serán más sencillos ya que tendremos mucho más organizados nuestros ficheros de configuración.

Mientras he escrito este post, he estado escuchando a los Misfits y ahora es vuestro turno.

Como posicionar Objetos en pantalla cuando trabajamos con Silverlight.

Tiempo hace que desarrollamos en la web, y por eso, nos hemos acostumbrado a ir posicionando objetos en función de un Layout que resulta de la aplicación de estilos css a elementos HTML. Cuando hemos trabajado con flash (o con algún Windows Form), posicionar objetos, es más sencillo, ya que simplemente tenemos que aplicarles unas coordenadas, posicionando estos objetos de forma absoluta.

Ahora que tenemos que aprender Silverlight (o Moonlight los linuxeros), con uno de los primeros problemas que nos vamos a encontrar, es con el posicionamiento de los elementos en pantalla. No os asustéis, porque no es muy complicado, pero sí que es verdad que tenemos varias opciones donde elegir, las cuales vamos a ver en breve.

Posicionando elementos en pantalla.

Silverlight, para permitirnos posicionar los elementos en pantalla de una forma flexible, nos proporciona tres controles:

• StackPanel
• Canvas
• Grid

Estos 3 elementos, nos van a permitir, posicionar otros elementos de formas más bien distintas.
Los 3 heredan de la clase Panel, y ahora vamos a ver con que funcionalidad nos fortalecen o penalizan cada vez que usemos uno de ellos.

El StackPanel.

El StackPanel, es el más sencillo de los tres, nos permite posicionar varios elementos, uno a continuación de otro y en dirección horizontal o vertical.

El código XAML necesario es el siguiente:

Dependency Properties y Attached Properties, ¿Qué son?

Cuando estas empezando a aprender Silverlight o Windows Presentation Foundation (aka WPF) y las tecnologías lo hacen posible como por ejemplo XAML, empiezas a encontrar algunos conceptos nuevos que ha introducido ASP.NET 2008 y el Framework 3.5.

WPF, introduce un nuevo uso de las propiedades mucho más inteligente y sofisticado, estas son las Dependency Properties y las Attached Properties, dos tipos nuevos de propiedades (o un tipo y medio por lo menos) que nos proporciona el Framework y que nos vamos a cansar de usar cuando nos toque crear interfaces (y lo que no son interfaces) con XAML.

Dependency Properties

Una Dependency Property, es un tipo especial de propiedad que devuelve una propiedad .NET y además el valor de la susodicha Dependency Property, depende de otros elementos, por eso no es suficiente con una propiedad normal.

Las características de las Dependency Properties son:

Los selectores propios de JQuery. Seleccionando un conjunto de elementos del DOM: El uso del alias $ cuando trabajamos con JQuery.

Para finalizar la línea de post que habla de la (gran) potencia de selección de la que goza JQuery, solo nos queda ver, los selectores propios de JQuery. Como ya hemos visto en anteriores post, una de las principales características de JQuery es que podemos seleccionar un conjunto de elementos de una forma muy simple, potente y elegante. Esta funcionalidad nos la proporciona la función $ (alias de objeto JQuery), pero no solo puede hacer esto, sino que también nos permite:

• Estable el ciclo de vida del código.
• Seleccionar un conjunto de elementos del DOM.
  • Selección básica con selectores CSS.
  • Selecciones por medio de atributos, hijos y contenedores.
  • Selecciones por medio de la posición.
  • Selecciones gracias a los selectores que nos proporciona JQuery.
• Sirve como namespace para usar funciones globales.
• Crea elementos del DOM en base a código HTML.

Los selectores propios de JQuery.

JQuery, para completar la capacidad de selección de la que goza nos proporciona una serie de selectores propios. Estos selectores nos van a permitir realizar acciones que por su naturaleza o finalidad no las podemos realizar con selectores CSS. Supón que quieres seleccionar todos los checkboxes chequeados. Este tipo de acciones son las que nos permiten realizar los selectores propios de JQuery. Veamos cuales son:

Selectores basados en la posición. Seleccionando un conjunto de elementos del DOM.

Volvemos a hablar de JQuery y seguimos con los selectores (aunque ya queda poco). Hoy vamos a ver los selectores que se basan en la posición de un objeto dentro del árbol del DOM de la página. Recordar que para poder seleccionar un conjunto de elementos, lo hacemos mediante la función $ (alias del objeto JQuery). Esta función tiene 4 usos principales:

• Estable el ciclo de vida del código.
• Seleccionar un conjunto de elementos del DOM.
  • Selección básica con selectores CSS.
  • Selecciones por medio de atributos, hijos y contenedores.
  • Selecciones por medio de la posición.
  • Selecciones gracias a los selectores que nos proporciona JQuery.
• Sirve como namespace para usar funciones globales.
• Crea elementos del DOM en base a código HTML.

Seleccionando un conjunto de objetos del DOM en función de la posición.

Algunas veces, nos vamos a encontrar con la tesitura de querer seleccionar un conjunto de objetos del DOM, en función de la posición que tienen en la página o en función de la relación que tienen con otros objetos.

Selectores basados en atributos, hijos y contenedores padres. Como seleccionar un conjunto de elementos del DOM

Siguiendo con la línea de post sobre JQuery, hoy vamos a continuar con los selectores. Vamos a ver cómo realizar selecciones en base a atributos, hijos y contenedores, pero antes, recordemos que hace la función $ (el alias del objeto JQuery).

• Estable el ciclo de vida del código.
• Seleccionar un conjunto de elementos del DOM.
• Sirve como namespace para usar funciones globales.
• Crea elementos del DOM en base a código HTML.

Como he dicho vamos a seguir hablando sobre cómo seleccionar un conjunto de elementos del DOM. JQuery, para seleccionar elementos lo realiza por medio de las siguientes acciones:

• Selección básica con selectores CSS.
• Selecciones por medio de atributos, hijos y contenedores.
• Selecciones por medio de la posición.
• Selecciones gracias a los selectores que nos proporciona JQuery.

Selecciones por medio de atributos, hijos y contenedores.

Estos selectores, son más avanzados que los basados en los selectores CSS. Aun así, están basados en la siguiente generación de selectores CSS (que ya esta soportada por Firefox, IE7, Safari etc…). Estos selectores incluyen selección en función de atributos (en base a una condición), e hijos (directos) de un objeto padre.