Archive for September 28, 2009

The complex way is not really the right way…

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

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

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…

XUnit.NET Extensions, TheoryAttribute y DataAttribute

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 ;)

My blog was offline… again…

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, FreezeClock

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);
}