¿Estamos realizando TDD cuando usamos frameworks para simular dependencias?

23 views
Skip to first unread message

Carlos Durbán

unread,
Nov 28, 2011, 10:18:51 AM11/28/11
to TDDev
Llevo dandolé vueltas a esto, haber si me podéis aclarar un poco
alguna duda que tengo.

Al desarrollar mediante TDD siempre escribimos el test antes que el
SUT. Para este caso voy a poner un ejemplo bastante claro.

Necesito crear una objeto que dependeciendo de la hora del sistema me
diga si es de dia o si es de noche.

Mi primer test podria ser así. No tengais en cuenta el código por
favor.

[Test]
public void It_is_Day()
{
bool IsDay = new DayChecker().ItisDay();
Assert.IsTrue(IsDay);
}

Implementación;

public class DayChecker
{

public bool ItIsDay()
{
return DateNow.Hour >= 8 DateNow.Hour <= 18;
}

}


Desde el primer momento nos damos cuenta que este test funcionará sólo
cuando estemos entre las 8 de la mañana y las 6 de la tarde.
Deberiamos eliminar la dependencia de DateNow.

interface IDateService
{
DateTime GetDate();
}

Modificamos el test

[Test]
public void It_is_Day()
{
var fakeTimeService = new Mock<IDateService>();

fakeTimeService.except(x => x.ItIsDay()).return("8");

bool IsDay = new DayChecker(fakeTimeService).ItisDay();

Assert.IsTrue(IsDay);
}

Y aquí viene mi duda si usamos un framework dinámico de mocks,
necesitamos conocer y pensar como vamos a escribir el código del SUT.
Yo pensaba que esto erá lo que debiamos evitar al seguir TDD.
Concentrarnos en el api externo de las clases, como se usan, como
colaboran los objectos entre si y no en el código interno del SUT
hasta que no estuviera escrito el primer test. No se si me he
explicado bien...

Saludos

Alfredo Casado

unread,
Nov 28, 2011, 10:40:46 AM11/28/11
to tdde...@googlegroups.com
En este lo que yo haría es hacer el test con mocks desde el principio, para simular las condiciones necesarias para el test necesito controlar el tiempo y para esto la única forma el que tiempo te lo entregue un colaborador y que ese colaborador este bajo tu control, más que de un mock se trataría de un stub en este caso.

Ten en cuenta que con esto tampoco esta pensando en la implementación interna antes de hacer el test, estas pensando en la interfaz externa y en la relación que va a tener tu objeto a implementar con sus colaboradores. De otro modo, piensas en los mensajes que recibe tu objeto (el interfaz que recibe el test) y piensas en los mensajes que envía tu objeto a otros colaboradores.

De esta forma estas diseñando tu red de objetos y los mensajes que se intercambian al hacer el test, la implementación interna en este caso consiste en como a partir de la información de la hora decides si es de día o de noche, y eso no esta apareciendo en tu test en ningún sitio, vamos que no te estas acoplando en ningún momento a tu implementación interna en el test que es el peligro que a veces se corre con los mocks.

Si te lees el GOOS veras que su forma de hacer TDD es precisamente así, pero constantemente no sólo porque sea una fecha o algún caso dificil de este estilo, mockeando siempre y diseñando en los test la red de objetos y los mensajes que se intercambian.

Sólo un detalle, ¿porque una interfaz para el DateService?, ¿hasta que no tengas una segunda implementación para que sirve un interfaz?, y si es algo a lo que te obliga tu framework de mocks cambialo por otro que permita mockear clases. Otro de los olores horribles cuando se empieza con mocks es acabar con una relación 1:1 entre clases e interfaces, algo que si lo piensas no tiene ningún sentido.

2011/11/28 Carlos Durbán <kak...@gmail.com>

--
Has recibido este mensaje porque estás suscrito al grupo "TDDev" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a tdde...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a tddev-sp+u...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/tddev-sp?hl=es.


Carlos Durbán

unread,
Nov 28, 2011, 10:54:08 AM11/28/11
to TDDev
Gracias Alfredo, entonces sigo como hasta ahora. De todas maneras
tienes muchas razón en que algunas veces he terminado con no se
cuantas interfaces o clases abstractas para poder crear los mocks un
buen smell como dices.

Revisaré la documentación y veré si puedo hacer uso de la clase real.
Sobre el libro no lo conocía, lo miraré con detalle!

Gracias de nuevo

> 2011/11/28 Carlos Durbán <kake...@gmail.com>

Reply all
Reply to author
Forward
0 new messages