Mocks Object

Un mock es un tipo concreto de doble de test. La expresión “doble” se usa en
el mismo sentido de los actores “dobles” en las películas de acción, ya que se
hace pasar por un colaborador del SUTo CUT cuando en realidad no es la
entidad que dice ser.
El stub es como un mock con menor potencia, un subconjunto de su
funcionalidad. Mientras que en el mock podemos definir expectativas con
todolujo de detalles, el stub tan sólo devuelve respuestas preprogramadas
a posibles llamadas. Un mock valida comportamiento en la colaboración,
mientras que el stub simplemente simula respuestas a consultas

Los frameworks que generan mocks y stubs son muy ingeniosos.
Son capaces de crear una clase en tiempo de ejecución, que hereda de una
clase X o que implementa una interfaz Y. Tanto X como Yse pueden pasar
como parámetro para que el framework genere una instancia de un mock o un
stub que sea de ese tipo pero cuya implementación simplemente se limita a
reaccionar tal como le indiquemos que debe hacerlo

Supongamos que hemos escrito un control gráfico que muestra un calendario en
pantalla para permitirnos seleccionar una fecha. Ahora nos piden que dibujemos los
días festivosde determinados municipios en un color distinto, para lo cual tenemos
que consultar un servicio remoto que lee, de una base de datos, los días festivos. El
servicio necesita conocer qué año, qué mes y qué municipio nos ocupa, para devolver
un vector con los días festivos del mes. La interfaz del servicio remoto es la siguiente:
public interface ICalendarService
{
int[] GetHolidays(int year,int month, string townCode);
}
Lo que queremos diseñar es el trozo de código, de nuestra aplicación cliente, que
obtiene los días festivos del servidor remoto. El SUT es el calendario cliente y su
colaborador el servicio remoto
Para diseñar la colaboración, no vamos a utilizar el servicio real porque el test no
sería unitario, no se ejecutaría de manera veloz ni con independencia delentorno

Using NUnit.Framework;
Using Rhino.Mocks;
[TestFixture]
public class CalendarTests
[Test]
public void ClientAsksCalendarService()
Arrange (El primer bloque consiste en la generación del mock y la definición de expectativas.
Se define la primera expectativa (Expect) y dice que, sobre el propio objeto mock, en algún
momento, se invocará al método GetHolidays con sus tres parámetros.Y además, dice que,
cuando esa invocación se haga, el mock devolverá un array de dos elementos, 1 y 5 ). Estamos
diciéndole al mock que le van a invocar de esa manera y que, cuando ocurra, queremos que se
comporte tal cual.
{int year = 2009; int month = 2; string townCode = "b002";
ICalendarService serviceMock = MockRepository.GenerateStrictMock();
serviceMock.Expect(x =>x.GetHolidays(year, month, townCode)).Return(new int[] { 1, 5 });
Act donde se invoca al SUT
Calendar calendar = new Calendar(serviceMock);
calendar.CurrentTown = townCode;
calendar.CurrentYear = year;
calendar.CurrentMonth = month;
calendar.DrawMonth(); // the SUT
Assert Le dice al mock que compruebe que la expectativa se cumplió. Si no se cumplió,
entonces el test no pasa porque el framework lanza unaexcepción. Que no se cumplió significa
que la llamada nunca se hizo o que se hizo con otros parámetros distintos a los que
explícitamente se pusieron en la expectativa o bien que se hizo más de una vez.
serviceMock.VerifyAllExpectations();

Además, si en el acto se hacen llamadas al mock que no estaban contempladas en las
expectativas (puesto que solo hay una expectativa, cualquier otrallamada al servicio
sería no-contemplada), el framework hace fallar el test. La ausencia de expectativa
supone fallo, si se produce alguna interacción entre SUT y mock, al margen de la
descrita explícitamente. Esta es una restricción o una validación importante, según
cómo se mire. Si el colaborador fuese un stub, la verificación (y por tanto sus
restricciones), no se aplicaría, como veremos a...