viernes, 24 de octubre de 2008

Ágiles 2008, una utopía hecha realidad

Bueno, han finalizado las primeras jornadas latinoamericanas sobre metodologías ágiles, de las cuales tuve el hornor de participar en la organización. Fueron diez meses desde el puntapié inicial en la lista de laass, luego de muchos desalientos, tropezones y otras yerbas, finalizaron ayer con el salón Bolivar del hotel Bauen a pleno para ver un panel de cierre de lujo formado por Mary y Tom Poppendieck, Tobiar Mayer, Matt Gelbwaks, Dave Nicolette y Micah Martin, esto lo tenemos filmado y vamos a ver cómo hacemos para subirlo.

 Unas últimas palabras de Martín Salías para emocionarnos a todos que son un poco el resumen de los que pasó, no puedo agregar nada a lo que dijo Martín, un gran agradecimiento a todas las personas que fueron y a todos los organizadores, creo que todos nos llevamos una experiencia única y momento que van a quedar grabados para siempre, como la foto final de todo el equipo que demuestra que las personas son lo más importante, tuve la oportunidad de interactuar la mayoría y no tengo más que elogíos para todos por su entrega y su calidez personal, gracias chicas y chicos y veremos qué pasa el año próximo.

Foto del salón bolivar durante el panel de cierre (cortesía del blog de Martín)

martes, 14 de octubre de 2008

Moq 2.6: Mocks recursivos

Automocking con Moq

Una de las novedades de la versión 2.6 de nuestro framework de mocking preferido Moq es al automocking que no es otra cosa más que un mockign jerárquico, es decir si "mockeamos" un objeto (interface o lo que sea) y este tiene dentro otros objetos también se hace mocking de estos y podemos configurar un resultado o comportamiento de cualquiera de ellos, lo cual es muy práctico, veamos cómo funciona.

public interface IPersona
{
    string Nombre { get; set; }
    //La propiedad Direccion es otro objeto
    IDireccion Direccion { get; set; }
}

public interface IDireccion
{
    string Calle { get; set; }
    int Altura { get; set; }
}

[TestMethod]
public void AutoMocking()
{
    var mock = new Mock<IPersona>();

    //automáticamente se crea un mock object para la propiedad Dirección de modo lazy
    mock.Expect(persona => persona.Direccion.Calle).Returns("Cucha Cucha");

    Assert.AreEqual<string>("Cucha Cucha", mock.Object.Direccion.Calle);
}

No nos asustemos pensado que esto va a hacer que el automocking tome 40 segundos en crear un objeto hasta que resuelve todos los objetos que tiene dentro, la creación de los automocking es del tipo lazy, es decir, se crea sobre demanda, mágico. Saludos.

viernes, 10 de octubre de 2008

Charla en el Microsoft User Group de Argentina, sobre Mocking

Charla en el Microsoft User Group de Argentina

Finalmente llegó el día, el próximo 18 de Noviembre voy a estar dando una charla en el MUG, el título será:

Mock Objects como solución para pruebas en ambientes complejos.

La misma estará orientada a desarrolladores y equipos que utlizan pruebas de unidad y son concientes de la problemática de probar componentes con depencias de otros componentes que van más allá del ámbito de la prueba, como interfaces, repositorios de datos, conexiones de red, etc.

La idea es hablar un poco del modelo de mocking basado en inyección de dependencias, es decir, como Rhino Mocks y Moq, y a lo sumo nombrar TypeMock Isolator, hacer unos ejemplos de dependecias de componentes y ver cómo se pueden diseñar las aplicaciones para disminuir el acoplamiento y poder utlizar mocking para crear pruebas unitarias de calidad, vamos a ver un poco de Rhino y mucho de nuestro framework preferido Moq, todo a través de ejemplos.

Tengo que agradecer por esta oportunidad a la gente del MUG por supuesto y especialmente a Daniel Laco.

El link de la charla es este

http://www.mug.org.ar/Eventos/3125.aspx

Nos vemos en el MUG.

lunes, 6 de octubre de 2008

¿Cómo verificar la cantidad de llamadas a un miembro con Moq?

¿Cómo verificar la cantidad de llamadas a un miembro con Moq?

Si hay utlizado Moq como yo también Rhino Mocks seguramente se han encontrado con la ausencia de un modo de verificar la cantidad de llamadas que se hacen sobre un miembre, digamos propiedad o método, o sea, configuramos nuestras Expectations y de alguna manera queresmos asegurarnos que tal miembro es llamado un número exácto de veces, es se hace en Rhino más o menos así

[TestMethod]
public void VerificarCantidadDeLlamadasConRhino()
{
    Rhino.Mocks.MockRepository mocker = new Rhino.Mocks.MockRepository();

    var mock = mocker.CreateMock<IFoo>();

    using (mocker.Record())
    {
        Rhino.Mocks.Expect.Call(mock.DoInt(2)).Return(22).Repeat.Times(3);
    }

    //Rhino hace la verificación al salir del bloque using
    using (mocker.Playback())
    {
        Assert.AreEqual<int>(22, mock.DoInt(2));
        Assert.AreEqual<int>(22, mock.DoInt(2));
        Assert.AreEqual<int>(22, mock.DoInt(2));
    }
}

 

Ahora bien, nuestro querido Moq no dispones de esa característica,¿ por qué?, porque la idea de Kzu es que Moq sea muy sencillo (no entremos en discusiones del tipo por qué se mezclan Stubs y Mocks porque no tienen sentido) esto es muy bueno y la verdad es que me encanta, pero nos deja con ese problema, cómo lo resolvemos?

Callbacks, la solución

Los Callbacks son acciones que podemos indicar al Moq que realize un Mock cuando se invoca a uno de sus miembros, o sea, configuramos un Expectation a un miembro y de paso le podemos decir a Moq que cuando este miembro sea invocado que haga algo más que puede no tener ninguna relación con el Mock, entonces lo que tenemos que hacer para verificar que un método es llamado un número exácto de veces (o mayor o menor, lo que sea) es configurar un Callback en el miembro que incremente un contador y luego con un Assert verificar el contador, y listo el pollo, de esta manera:

[TestMethod]
public void VerificarCantidadDeLlamadasConMoq()
{
    var mock = new Mock<IFoo>();
    int contador = 0;

    //al configurar el Expectation agregamos un Callback que incrementa contador
    mock.Expect(x => x.DoInt(2)).Returns(22).Callback(()=>contador++);

    Assert.AreEqual<int>(22, mock.Object.DoInt(2));
    Assert.AreEqual<int>(22, mock.Object.DoInt(2));
    Assert.AreEqual<int>(22, mock.Object.DoInt(2));

    //verificamos contador y listo
    Assert.AreEqual<int>(3,contador);
}

Conclusión

Personalmente me sigue pareciendo mucho más clara la sintáxis de Moq, en definitiva puede ser que Moq sea demasiado sencillo y mezcle conceptos de TDD para serlo, pero la realidad es que es mejor ser productivo que ortodoxo, no? hasta la próxima.