IDisposable Thoughts

The complex way is not really the right way…

2009-09-29T01:12:00+00:00

Today I was visiting a client, and I just stop and watch something that really caught my attention:

// Ugly code is over
foreach (item in myList) {
    if (item.Length > 0) {
        SaveItem(item);
    }
}
// more ugly code...

Well, the code was really different (an uglier one) but you got the idea…. What I suggested to my client was a more concise solutio, create an extension method:

public static class IEnumerableExt {
    public static IEnumerable<T> ForEach(this IEnumerable<T> items, Action<T> action) {
        foreach(var item in items) {
            action(e);
        }
    }
}

The second part is the easy one…

myList
    .Where((item) => item.Length > 0)
    .ForEach((item) => SaveItem(Item));

I don’t know you, but this way looks a lot clearer to me…

Lessson learned: If your code looks complex, please, take a time and look how to make it more clearer.

Sharepoint Development = GDD

2009-09-21T22:15:00+00:00

Yep, in the last few weeks I’ve committed to develop a few Sharepoint + Infopath based workflows for a client, I’ve been developed sharepoint solutions before, and everytime I touch sharepoint solution code I arrive to the same conclusion:

Sharepoint development is the best example of GDD (Guess Driven Development)

I mean, I know there are just a few ways to do TDD in Sharepoint (using Typemock), but right now develop and test complex sharepoint solutions consist in a few steps:

Think what you need to do
Guess how to do it
Guess what would happen in sharepoint when the solution is deployed
Build your WSP
Deploy your WSP
Run it
Guess what that “cryptic” error message means…
Guess your solution to that error
Repeat until your error message disappears or another one appears.

I think there must be a better way to do it…

My blog was offline… again…

2009-09-19T04:37:00+00:00

Well, after a short amount of time my blog was offline, and, of course, my blog data was lost… yep, another “home run” from my ex-hosting provider. Now, I changed from provider and restored ‘at hand’ a few of my post (which was stored on my live writer local recently posted files). I hope this will happen never again...

XUnit.NET Extensions, TheoryAttribute y DataAttribute

2009-09-11T03:48:00+00:00

Es bastante común toparnos con casos en los que debemos asegurarnos que el mismo test se cumpla para varias condiciones. Imagínense el desarrollo de una calculadora o mucho mejor, el de alguna pieza de lógica de negocio dependiente de data. En vez de escribir ciclos dentro de nuestro test o peor aún, escribir varios test para el caso, en XUnit.NET tenemos el apoyo de las “Theory” que son test que estan fuertemente ligados a los datos.

Los datos son pasados como parámetros del test y el origen de los datos depende de nuestro proveedor de datos seleccionado. En XUnit.NET Extensions tenemos de “cajita” varios proveedores de datos que podemos usar:

InlineDataAttribute, los datos se presentan en línea en cada atributo
ClassDataAttribute, los datos son proporcionados por una clase que implementa IEnumerable<T>
PropertyDataAttribute, los datos son entregados por la propiedad de una clase que retorna IEnumerable<T>
SqlServerDataAttribute, los datos vienen de una consulta de una base de datos de SQL Server
OleDbDataAttribute, los datos tienen como origen una consulta de un proveedor OleDb
ExcelDataAttribute, los datos tienen como origen una hoja de cálculo de Excel.

El uso de Theory y DataAttribute proporciona una agilidad increíble al probar ciertas condiciones que antes requeririan mucha más pericia. Depende de nosotros sacarle provecho :)

[Theory]
[InlineData(1, 2, 3)]
[InlineData(4, 5, 9)]
public void It_can_use_correctly_the_data_attribute(int a, int b, int result)
{
    Assert.Equal(result, (a + b));
}

[Theory, ExcelData("myTestData.xls", "SELECT a, b, result FROM Data")]
public void It_can_use_correctly_the_data_from_an_excel_file(int a, int b, int result)
{
    Assert.Equal(result, (a + b));
}

Bien, hasta aquí llegamos con las Extensiones de XUnit.NET, la próxima entrega veremos como extender a nuestro antojo XUnit.NET ;)

XUnit.NET Extensions, Trace y AutoRollback

2009-09-10T02:51:00+00:00

A veces es necesario (por alguna razón extraña), mostrar el inicio y el fin de un test en la consola, con el tiempo de inicio y tiempo de fin (imaginémonos un test de performance sencillo); para esos menesteres tenemos a nuestro amigo TraceAttribute, que no hace más que enviar a la salida Trace el inicio y el fin del test, un atributo sencillo de entender.

[Fact, Trace]
public void Must_sent_to_trace_console_start_and_end_time_of_test()
{
    Assert.True(true);
}

AutoRollbackAttribute

Comunmente cuando trabajamos con bases de datos, es bastante común el toparnos con transacciones, o mejor aún, toparnos con código que para simplificarnos las cosas debería correr dentro de una transacción. Por ejemplo, un test contra la base de datos que haga ciertos inserts, pero al final del test no nos importa el resultado y simplemente descartamos la transacción, por lo tanto nada fue insertado o modificado en la base de datos. Para esas tareas tenemos al atributo AutoRollbackAttribute, que simplemente al inicio del test crea una transacción y al final del test descarta la transacción. Es dificil probar código transaccional, pero con la “descripción” de que realiza el test, simplemente podemos ver si hay o no una transacción creada.

// NOTE: It Requires referece to System.Transactions
[Fact]
public void When_no_autorollback_is_present_there_is_no_transaction()
{
    Assert.Null(Transaction.Current);
}

[Fact, AutoRollback]
public void When_autorollback_is_present_there_is_a_transaction()
{
    Assert.NotNull(Transaction.Current);
}

XUnit.NET Extensios, FreezeClock

2009-09-09T03:59:00+00:00

FreezeClock es uno de esos atributos maravillosos de XUnit.NET, nos permite “congelar” el reloj (tal como lo dice su nombre) en un tiempo dado y de esa manera comprobar que operaciones que dependen de tiempo se lleven acabo exitosamente. En versiones anteriores a la 1.5 FreezeClock cambiaba el tiempo mostrado por DateTime.Now, pero esto causaba problemas con ciertas implementaciones, así que en XUnit.NET 1.5 se debe utilizar la clase Clock y su propiedad Now (Clock.Now) en vez de DateTime.Now para efectos de las pruebas, de igual manera podríamos ver a Clock.Now como un clon de DateTime.Now en todos sus sentidos.

[Fact]
public void It_should_fail_because_clock_are_not_frozen()
{
    var clock1 = Clock.Now;
    Thread.Sleep(1000);
    var clock2 = Clock.Now;
    Assert.NotEqual(clock1, clock2);
}

[Fact, FreezeClock]
public void It_should_pass_because_clock_are_frozen()
{
    var clock1 = Clock.Now;
    Thread.Sleep(1000);
    var clock2 = Clock.Now;
    Assert.Equal(clock1, clock2);
}

[Fact]
public void Clock_time_must_be_lesser_than_a_second_different_from_now()
{
    var now = DateTime.Now;
    var clock = Clock.Now;
    Assert.True((clock - now).Milliseconds < 1000);
}

XUnit.NET Extensions, AssumeIdentity

2009-09-08T04:01:00+00:00

Una de las excelentes características y habilidades de XUnit.NET es su capacidad de ser extendido en muchas formas. Como parte del “paquete” de XUnit.NET, se incluye una librería adicional con atributos extras para cambiar en cierta manera el comportamiento de un test mientras realizamos las pruebas. A esta librería se le llama XUnit.NET Extensions y viene incluída con el download de XUnit.NET. Veremos algunos de los atributos extras incluídos con XUnit.NET Extensions.

El primero en ver será AssumeIdentity, este atributo permite cambiar el Principal de la actual Thread de ejecución y agregarle el rol indicado por el atributo. Por defecto la thread de ejecución del test corre bajo el principal con la identity de “xunit”.

[Fact]
public void It_should_fail_because_user_has_no_role()
{
    Assert.False(Thread.CurrentPrincipal.IsInRole("fake_role"));
}

[Fact]
[AssumeIdentity("fake_role")]
public void It_should_pass_because_user_is_in_role()
{
    Assert.True(Thread.CurrentPrincipal.IsInRole("fake_role"));
}

Voilà! Luego converaremos de los otros atributos disponibles en este namespace.

XUnit.NET y las Colecciones

2009-08-28T04:03:00+00:00

Continuando con mi corta serie acerca de XUnit, algo que es sumamente útil en las pruebas es verificar si un item se encuentra o no en una colección. En XUnit.Net esto es sumamente fácil, simplemente usamos los métodos Contains y DoesNotContains los cuales también funcionan con strings.

private readonly int[] numbers = {1, 2, 3, 4, 5, 6};

[Fact]
public void It_must_return_true_if_number_is_in_collection()
{
    Assert.Contains(1, numbers);
}

[Fact]
public void It_must_return_true_if_number_is_not_in_collection()
{
    Assert.DoesNotContain(7, numbers);
}

[Fact]
public void It_must_return_true_if_string_contains_substring()
{
    Assert.Contains("hola", "hola mundo");
}

[Fact]
public void It_must_return_true_if_string_does_not_contains_substring()
{
    Assert.DoesNotContain("adios", "hola mundo");
}

De igual manera tenemos métodos para verificar si una colección se encuentra vacía o no, obviamente nuestros métodos en cuestion seran Empty y NotEmpty (estos no funcionan con strings).

private int[] numbers = { 1, 2, 3, 4, 5, 6 };

[Fact]
public void It_must_return_true_if_collection_is_not_empty()
{
    Assert.NotEmpty(numbers);
}

[Fact]
public void It_must_return_true_if_collection_is_empty()
{
    int[] empty = {};
    Assert.Empty(empty);
}

Creando instancias a partir del nombre y assembly de la clase

2009-08-26T03:15:00+00:00

Entre las cosas interesantes que muchos hacemos a diario (o bueno, configuramos a diario) y que muy pocas veces nos preguntamos ¿cómo lo hicieron? esta el uso de handlers o providers en la .Net Framework. Por ejemplo, muchas veces vemos algo como:

<viewStatePersisters default="cachePersister">
    <persisters>
        <add name="pagePersister" type="Rioshu.Web.ViewStateHandlers.TinyPagePersister, Rioshu.Web.ViewStateHandlers" />
        <add name="cachePersister" type="Rioshu.Web.ViewStateHandlers.WebCachePersister, Rioshu.Web.ViewStateHandlers" />
    </persisters>
</viewStatePersisters>

Y asumimos correctamente que la framework tomará esa información e instanciará el manejador o clase correspondiente que hemos indicado por su Full Qualified Name. ¿Cómo hace la framework para cargar el tipo correcto en el assembly correcto y luego instanciarlo?. La respuesta es simple, una mezcla de propiedades del tipo del objeto y a un amigo llamado “Activator”.

Cuando me refiero al “tipo del objeto” no me refiero a si es Integer, String u Object. En la .Net Framework existe un “objeto especial” cuya responsabilidad es brindar información acerca del “tipo”, este objeto es System.Type, bien, Type tiene un método especial llamado GetType, al cual podemos pasarle el Full Qualified Name de la clase y el .Net Assembly and Type Loader intentará cargarlo.

public class TypeLoaderFacts
{
    private const string ExternalTypeName = "ExternalLibrary.ExternalServiceImplementation, ExternalLibrary";
    
    [Fact]
    public void It_can_load_a_type_by_his_fqn()
    {
        var type = Type.GetType(ExternalTypeName);
        Assert.Equal(typeof(ExternalServiceImplementation), type);
    }
}

Bien, con cargar el tipo no hacemos mucho, es hora de inicializarlo.

public class TypeLoaderFacts
{
    private const string ExternalTypeName = "ExternalLibrary.ExternalServiceImplementation, ExternalLibrary";

    private Type ExternalType;
    
    public TypeLoaderFacts()
    {
        ExternalType = Type.GetType(ExternalTypeName);
    }

    [Fact]
    public void It_can_load_a_type_by_his_fqn()
    {
        Assert.Equal(typeof(ExternalServiceImplementation), ExternalType);
    }

    [Fact]
    public void It_can_ctor_a_type()
    {
        var instance = Activator.CreateInstance(ExternalType);
        Assert.NotNull(instance);
    }
}

Pero como ustedes siguen también buenas prácticas, recordaran que es buena idea programar en base a interface y no a una clase concreta, así que podemos preguntarle al tipo si implementa la clase (algo que vamos a hacer usando un pequeño método de extensión).

public class TypeLoaderFacts
{
    private const string ExternalTypeName = "ExternalLibrary.ExternalServiceImplementation, ExternalLibrary";

    private Type ExternalType;
    
    public TypeLoaderFacts()
    {
        ExternalType = Type.GetType(ExternalTypeName);
    }

    [Fact]
    public void It_can_load_a_type_by_his_fqn()
    {
        Assert.Equal(typeof(ExternalServiceImplementation), ExternalType);
    }

    [Fact]
    public void It_can_ctor_a_type()
    {
        var instance = Activator.CreateInstance(ExternalType);
        Assert.NotNull(instance);
    }

    [Fact]
    public void It_implements_our_interface()
    {
        Assert.True(ExternalType.IsImplementationOf<IExternalService>());
    }
}

Bien, les queda de tarea el averiguar como crear el extension method en cuestion :)

Como ven es sumamente fácil llegar a implementar dynamic loaders en base a un archivo de configuración de esta manera (‘ala’ web.config de asp.net o NHibernate).

Como siempre cualquier comentario estamos a un mensaje de distancia!

XUnit.NET y las Excepciones

2009-08-24T04:09:00+00:00

El día de ayer publiqué mi primer post corto acerca de XUnit.Net, e inmediatamente después alguien me hizo una pregunta, la cuál parafraseando va algo así:

“Puedo testear o ver el mensaje retornado por la excepción y así asegurarme que es una excepción específica”

No voy a discutir si esto esta bien o mal (en cuanto a la especificidad de la excepción), pero me parece interesante la pregunta. Como mencionamos ayer, podemos probar que una excepción es arrojada mediante el método “Throws” de la clase Assert:

public void ThrowOperation()
{
    throw new InvalidOperationException("My message");
}

[Fact]
public void TestAssertWithException()
{
    Assert.Throws<InvalidOperationException>(() => ThrowOperation());
}

El detalle es que Assert.Throws no solamente se asegura que la excepción fue arrojada, sino que efectivamente retorna la excepción al sistema como un retorno más, de esta manera podemos hacer cosas como:

public void ThrowOperation()
{
    throw new InvalidOperationException("My message");
}

[Fact]
public void TestAssertWithMessage()
{
    var ex = Assert.Throws<InvalidOperationException>(() => ThrowOperation());
    Assert.Equal("My message", ex.Message);
}

De esta manera no sólo podemos probar que la excepción es efectivamente arrojada, sino que también podemos probar sin ningún problema otros atributos de la excepción como tal. ¿Interesante verdad?

Cómo siempre, cualquier pregunta o comentario somos oidos abiertos :)

XUnit.NET para simples mortales

2009-08-22T04:11:00+00:00

Desde hace tiempo tengo ganas de escribir una serie de posts acerca de TDD y BDD, pero como siento que soy aún un minúsculo saltamontes en el gigantesco mundo de testing, decidí mejor comenzar por algo sumamente básico, qué tal si hablamos de XUnit.Net?

XUnit.Net es una testing framework creada por James Newkirk (ex-desarrolladore de NUnit) y Brad Wilson (ASP.NET developer en Microsoft) la cual agrega excelentes características a nuestra forma de realizar tests.

Una sola instancia de test object por método del test
No atributos de TearDown o SetUp, de tal manera que se usan los constructores de clase para inicializar el test y Dispose de IDisposable para finalizar el test
Sin atributos de ExpectedException, en vez de eso las excepciones son tratadas como un verdadero assert de la forma Assert.Throws
Uso extensivo de características de la Framework 2 en adelante (generics, delegados, expresiones lambda)
Número pequeño de atributos
Totalmente extensible (esta es la parte interesante)

Un típico test en NUnit podría lucir algo así:

[TestFixture]
class TddSample
{
    private string text = string.Empty;
    private DisposableObject objectToDestroy;
    
    [SetUp]
    public void SetUp()
    {
        objectToDestroy = new ObjectToDestroy();
    }    

    [TearDown]
    public void TearDown()
    {
        objectToDestroy.Dispose();
    }

    [Test]
    public void It_must_be_initialized_with_a_simple_text_in_ctor()
    {
        Assert.IsNotNull(objectToDestroy);
    }

    [Test]
    public void It_should_add_two_numbers()
    {
        var result = 1 + 1;
        Assert.AreEqual(2, result);
    }
    
    [Test]
    [ExpectedException(typeof(DivideByZeroException))]
    public void It_throws_when_a_number_is_divided_by_zero()
    {
        int i = 0;
        int j = 1;
        var result = j / i;
    }

    [Test]
    [Ignore("I want to break free!")]
    public void It_must_skip_this_test()
    {
        Assert.True(false, "This test would fail");
    }
}

Un equivalente en Xunit.Net podría verse así:

public class SimpleXunitTest : IDisposable
    {
        private readonly string text = string.Empty;
        private readonly DisposableObject objectToDispose;

        public SimpleXunitTest()
        {
            text = "hello world";
            objectToDispose = new DisposableObject();
        }

        [Fact]
        public void It_must_be_initialized_with_a_simple_text_in_ctor()
        {
            Assert.False(string.IsNullOrEmpty(text));
        }

        [Fact]
        public void It_should_add_two_numbers()
        {
            int result = 1 + 1;
            Assert.Equal(2, result);
        }

        [Fact]
        public void It_throws_when_a_number_is_divided_by_zero()
        {
            int i = 0;
            int j = 1;
            Assert.Throws<DivideByZeroException>(() => j/i);
        }

        [Fact(Skip = "I want to break free!")]
        public void It_must_skip_this_test()
        {
            Assert.True(false, "This test would fail");
        }

        public void Dispose()
        {
            objectToDispose.Dispose();
        }
    }

En el sitio del proyecto de XUnit.Net en Codeplex podemos encontrar más equivalencias entre NUnit y XUnit.Net. Una de las verdaderas riquezas de XUnit.Net (a mi criterio muy personal) es la librería adjunta con extensiones conocida como xunit.extensions.dll que contiene atributos especiales que no forman parte a simple vista de la framework de testing, pero nos pueden ayudar mucho en nuestras fixtures, por ejemplo: FreezeClock, o las grandiosas [Theory] con soporte para data inline en nuestros tests ;)

    public class SimpleXunitTest
    {
        [Theory]
        [InlineData(1, 2, 3)]
        [InlineData(2, 2, 4)]
        [InlineData(4, 5, 9)]
        public void It_should_add_two_numbers_correctly(int a, int b, int c)
        {
            var result = a + b;
            Assert.Equal(c, result);
        }
    }

La documentación indica varias formas de incluir la data para las “teorías”, que van desde la inline más simple hasta usar una base de datos y un archivo de Excel.

En cuanto a runners, XUnit soporta TeamCity, MSBuild, R# (mediante proyecto hermano XUnit.Contrib), TestDriven.Net y muchos otros.

Espero mi pequeña intro acerca de XUnit.Net les anime a probarlo. Saludos!

MVP Awarded

2009-07-04T04:17:00+00:00

No sé porqué no lo había posteado antes, pero el día 1 de Julio recibí el siguiente mail en mi inbox:

Estimado/a Cristian Prieto,
Enhorabuena. Nos complace presentarle el programa de nombramiento MVP de Microsoft® de 2009. Este nombramiento se concede a los líderes excepcionales de la comunidad técnica que comparten de forma activa su experiencia de alta calidad y de la vida real con otras personas. Le agradecemos especialmente la contribución que ha realizado en las comunidades técnicas en el área de ASP/ASP.NET a lo largo del pasado año.

Claro, esa es la versión “genérica” de un mail diciéndote que este año has sido galardonado como MVP, así que todo indica que ahora soy MVP en ASP.NET. Gracias a cada uno de ustedes, los que día a día han tenido que soportarme durante mis charlas, escuchar y aguantar mis quejas sobre que X ó Y no funciona como debería o sobre cómo debería hacerse el procedimiento X. Ahora más que nunca me dieron unas ganas increíbles de cooperar con la comunidad, ahora más que nunca creo que debemos instar más a la gente a mejorar con cada día, ahora más que nunca me siento en deseos de transformar a Morts en Elvis.

Gracias a todos, gracias amigos…