TDD Paso a Paso (5) Lunes como día no laborable

Anterior post 
Siguiente post 


Veamos ahora otro test, que como los anteriores, nos va a obligar a implementar mejor nuestro software en construcción.


Queremos configurar, sobre la semana básica, cuáles son los días laborables y cuáles son no laborables. En el anterior post, agregué la capacidad de especificar un nuevo día laboral. Ahora, quiero poder especificar que los lunes son no laborables. Este es el test que escribí:


 


[TestMethod]
public void SetMondayAsANonWorkingDay()
{
	WorkingDaysCalendar calendar = new WorkingDaysCalendar();

	calendar.AddDayOfWeekAsNonWorkingDay(DayOfWeek.Monday);

	DateTime monday = new DateTime(2012, 3, 12);
	Assert.AreEqual(monday.DayOfWeek, DayOfWeek.Monday);

	Assert.IsFalse(calendar.IsWorkingDay(monday));
}

 


Primero, no compila. Porque usa el método no existente, AddDayOfWeekAsNonWorkingDay . Lo creo, lanzando una excepción de no implementado, ejecuto el test, y da rojo. Pongamos el mínimo código que hace que esto funcione, con algún refactor de nombre de parámetros.


 


private DayOfWeek? workingDay;
private DayOfWeek? nonWorkingDay;

public bool IsWorkingDay(DateTime day)
{
	if (this.workingDay.HasValue && this.workingDay.Value == day.DayOfWeek)
		return true;

	if (this.nonWorkingDay.HasValue && this.nonWorkingDay.Value == day.DayOfWeek)
		return false;

	if (day.DayOfWeek == DayOfWeek.Sunday || day.DayOfWeek == DayOfWeek.Saturday)
		return false;

	return true;
}

public void AddDayOfWeekAsWorkingDay(DayOfWeek dayOfWeek)
{
	this.workingDay = dayOfWeek;
}

public void AddDayOfWeekAsNonWorkingDay(DayOfWeek dayOfWeek)
{
	this.nonWorkingDay = dayOfWeek;
}

 


Ahora el test está en verde. Agregué una nueva variable interna “nullable” nonWorkingDay. Ciertamente que la clase escrita sólo soporta un sólo día laborable configurable y un sólo día no laborable configurable. Pero los tests que escribimos pasan. Voy por “baby steps”, de a “pasos de bebé”.


Pero van viendo la aplicación de TDD: en cada test, hay una nueva especificación de cómo queremos que actúe nuestro software en construcción. Y sólo implementamos lo que necesitamos para pasar el test. Poco a poco, va emergiendo la implementación interna, donde ponemos lo que conocemos como programadores. Pero sin caer en la tentanción de “Ah! acá pongo esto que lo voy a necesitar”. Si el test no lo necesita, nosotros tampoco :-)


Nos leemos!


Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

This entry was posted in 10549, 11699, 3463, 5374. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *


*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>