Angel "Java" Lopez : TDD, ASP.NET MVC

Escribiendo una Aplicación usando TDD (Part 6) Modificando Vistas

lopez — Sun, 07 Apr 2013 11:33:39 GMT

El post de hoy va a mostrar que, al haber usado MVC (Model-View-Controller) podemos modificar nuestras vistas, sin necesidad de tocar el código. Ni siquiera tenemos que recompilar, en muchos casos.

Primero, una novedad: he pasado el ejemplo, paso a paso, a ASP.NET MVC 4, usando Visual Studio 2010. Y también lo pasé a mi cuenta de GitHub

https://github.com/ajlopez/TddAppAspNetMvc

Vean que cada versión (cada entrega por post) está señalada por tags. La de este post es la 0.0.5. Siempre pueden ver en

https://github.com/ajlopez/TddAppAspNetMvc/commits/master

Una de las cosas nuevas que me dió esta versión de ASP.NET MVC es el soporte de Razor, ahora las vistas están escritas con Razor. Como en el anterior post, use los “wizard” de creación de vistas del propio Visual Studio, y luego las modifiqué un poco (apenas algun texto).

En el paso de este post, lo que hice fue agregar Twitter Bootstrap:

Agregué estilos y javascript que necesita Bootstrap, y armé un _viewstart.chtml que le indica a Razor que todas las vistas usan un _Layout.cshtml

Vean cómo se ve ahora la página de Subjects:

Notablemente, no toqué nada de código ni de tests. Esto muestra que hasta se puede trabajar en paralelo, o en distintos tiempos: primero se arma el código de los controladores y acciones con tests. Luego, al mismo tiempo o en algun momento, se agregan y mejoran las vistas.

Próximos posts: agregar libros, aparición de primeros servicios, modelo de negocio, etc.

Nos leemos!

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

VAN en Alt.NET Hispano: Desarrollando una Aplicación con TDD

lopez — Mon, 18 Jun 2012 16:29:07 GMT

El sábado que viene, 23 de Junio, estaré en una VAN (reunión virtual) organizada por el grupo Alt.NET Hispano, tratando el tema de cómo desarrollar una aplicación con TDD. El horario es el habitual 18pm GMT, en Buenos Aires tenemos GMT-3, y es 3 de la tarde hora local.

Quiero mostrar cómo uso habitualmente TDD para ir desarrollando una aplicación. Usaré C#, una interfaz con ASP.NET MVC, y seguramente algún proyecto de clases donde ir poniendo el dominio. Estoy pensando más en detalle el dominio, quisiera uno que pudiera abarcar en las dos horas que tenemos disponibles, y que tuviera algunas reglas.

Para mí, es muy importante usar TDD en código en producción. Me ha resultado muy útil, no sólo por la cobertura de tests que me permite refactorizar con confianza, sino por el proceso de diseño del código y de la aplicación en sí. En los últimos años le he agregado también la idea de que lo importante son los casos de uso, y darle menos peso a temas como el diseño de la base de datos que puede aparecer más adelante en un desarrollo ágil, no tiene por qué estar desde el principio.

Ya escribí varios posts sobre desarrollo con TDD y mis proyectos personales públicos prácticamente están todos desarrollados con TDD (pueder ver mi cuenta de GitHub cómo van avanzando test a test). Pero no había tenido la oportunidad de mostrar esta técnica en una VAN sobre una aplicación y un dominio. Espero que pueda mostrar qué bueno es aplicar TDD desde el comienzo, y cómo nos ayuda en un desarrollo ágil.

Más información sobre Alt.NET Hispano en:

http://altnethispano.org/Inicio.aspx

Sobre las reuniones VAN y cómo participar en:

http://altnethispano.org/reuniones/descripcion.aspx

Las anteriores VAN han sido publicadas (en video) en:

http://altnethispano.org/reuniones/historico.aspx

El calendario de próximo eventos en:

http://altnethispano.org/reuniones/calendario.aspx

Nos leemos!

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

El Armado Agil de una Aplicación

lopez — Sat, 28 Jan 2012 17:34:09 GMT

En este nuevo año, estoy participando en la creación de una aplicación, en un equipo ágil, usando un Scrum-like (iteration reviews, planning, standups, iteration backlog, etc..). Tecnologías: .NET, C#, ASP.NET MVC, Azure, SQL Server, y más (en cualquier momento aparece JSON, REST, Javascript, jQuery, algún NoSQL, cache en memoria, etc…). Pero lo interesante de esta aplicación es que ha nacido prácticamente como “green field”. Si bien el proyecto completo tiene casi un año de existencia (y hasta tiene proyectos antecedentes que se remontan a 3 años atrás), la aplicación que le ha tocado a mi equipo es nueva: nace desde un File, New Project.

El proyecto es privado, así que no hay repositorio público para mostrar avance. Pero quería comentar en este post algunas de las estrategias que estamos usando para avanzar en el proyecto.

Primero: buscar basarnos en casos de uso. Anteriormente, el proyecto se basó demasiado (en mi parecer) en solucionar temas técnicos, sin llegar a hacer pie en lo que realmente se necesita. Entonces, desde la primera iteración (son semanales) nos concentramos en mostrar algo que funcione. Si bien hay varios riesgos técnicos a tomar en cuenta, no fueron (todavía) el centro de atención. Nos parece que para el cliente final lo mejor AHORA es mostrar algo andando, para que pueda explorar si es lo que necesita.

Veamos un ejemplo de estrategia: en vez de modelar el dominio con persistencia en la base de datos, lo principal del mismo ESTA EN MEMORIA, en objetos que solamente viven en memoria: persistencia, concurrencia, transacciones no están en la agenda actual, porque por las características del sistema (disculpen no dar más detalles, es privado) NO SON EL TEMA a tratar AHORA. Es mejor explorar una base de solución ahora, que tener todas las piezas en su lugar.

Como el cambio es constante (al aparecer nuevas historias, al reflexionar el cliente final sobre cómo quiere que quede el producto final, sus casos de uso), todo se ha ido construyendo con TDD (Test-Driven Development). El Code Coverage es > 85%, en general (incluido los controladores de vistas web, estamos usando ASP.NET MVC). Cuando hubo que cambiar algo en la segunda iteración (un refactor de los que yo llamo “quirúrgico”) todo esta en su lugar para que los tests nos ayudaran a comprobar que al cambiar la implementación interna todo siguiera funcionando como se esperaba.

Otro ejemplo: esta semana pasada, gran parte del dominio paso a estar persistida en SQL Server (y en Azure SQL Server). El lunes completamos la implementación de almacenamiento/persistencia en esa tecnología, usando TDD, luego la inyectamos en los lugares apropiados, y prácticamente no se rompió ningún test. En la entrega del viernes, tenemos parte del dominio en memoria (para hacer cambios rápidos) y parte en SQL Server (para ir explorando algo más cercano al producto final). Pero estamos preparados para cambiar esa persistencia a Azure Table Storage, si hace falta, y por qué no, al nuevo DynamoDB de Amazon. El desarrollo ágil y TDD nos da el “courage” (coraje) de abrazar el cambio.

TDD, en vez de ser un gasto de tiempo, es un gran avance: primero, nos sirve en el diseño de lo que implementamos. Luego, nos sirve en ir armando algo sin gastar tiempo en pruebas manuales o sesiones de depuración. Vamos avanzando de a “baby steps” (pasos de bebé): cada nueva característica se agrega con TDD, y la vamos integrando. Desplegamos en Azure más de una vez al día, para que el cliente final pueda ir viendo los avances. Las nuevas características se van anunciando en la lista del proyecto.

Otro ejemplo: el jueves se comenzó a implementar temas de seguridad (autorización en particular, con usuarios y grupos). ¿Acaso implementamos eso usando alguna tecnología? ¿Fuimos e instalamos Azman o cualquier otra cosa? ¿Fuimos a usar Access Control System, tokens y claims? No. Armamos los tests e implementamos la lógica (permisos, reglas) en memoria. El viernes ya estaba listo para la demostración, con distintos usuarios (de nuevo, definidos en memoria). De ahora en más, podemos tener retroalimentación del cliente y usuarios finales, sobre qué es lo que funciona o no del “approach” que adoptamos. Sabemos que alguna parte de la implementación puede sufrir en escalabilidad. Es parte de lo que tenemos en el radar. Pero, como digo, “no cruzar el puente antes de llegar al puente”. No es (en este proyecto en particular, cada uno de Uds. analizará su caso y contexto) lo PRIORITARIO ahora. En vez de estar semanas viendo cómo implementar eso con Azman, o con claims, o lo que sea, ya en dos días tenemos algo funcionando, listo para refactorizar a tecnología PORQUE TENEMOS los tests.

Claro que no todo tiene que ser un lecho de rosas. Pero, por lo menos yo, estoy muy contento y entusiasmado por este camino que tomamos. Espero que todo esto permita llevar a buen puerto un proyecto que ya lleva muchos meses dando vueltas.

Nos leemos!

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

Escribiendo una Aplicación usando TDD (Part 5) Agregando Vistas

lopez — Mon, 27 Jun 2011 10:21:00 GMT

Anterior Post
Próximo Post

Ahora ya tengo algunos tests y en verde. Voy a agregar algunas vistas MVC en este paso de hoy. Pueden bajar el código desde mi AjCodeKatas Google Project, en trunk/AppTdd/Step04. Así que este post tiene pocos nuevos tests: muestra que podemos agregar interfaz de usuario DESPUES de los tests, y (para destacar) SIN TENER una base de datos aún, ni siquiera una capa de servicios (“service layer”).

Primero, agregué una master page Site.master y un estilo style.css (que tomé de otro proyecto ASP.NET MVC 2)

Agregué un nuevo controlador Home:

Y usando el menú de contexto sobre el método Index agregué una vista asociada al método:

Modifiqué el código de la master page para tener una nueva opción en el menú:

Entonces, agregué una vista, esta vez asociada al método Index del controlador Subject:

Seleccioné a “List” como “Vien Content”, y a “Subject” como el tipo a usar como base del modelo.

Pero el método del controlador es:

public ActionResult Index()
{
    return View(subjects);
}

Usa una lista de temas (“subjects”) que ha sido inyectada hasta ahora en un constructor por los tests:

public SubjectController(IList<Subject> subjects)
{
    this.subjects = subjects;
}

Pero esperen! Esa lista es inyectada por los tests. Ahora, necesito que esté disponible en el proceso normal de un controlador. Así que agregué un constructor sin parámetros:

public SubjectController()
    : this(Domain.Instance.Subjects)
{
}

El Domain.Instance es un dominio en memoria:

public class Domain
{
    private static Domain instance = new Domain();
    private Domain()
    {
        this.Subjects = new List<Subject>()
        {
            new Subject() { Id = 1, Name = "Mathematics" },
            new Subject() { Id = 2, Name = "Physics" },
            new Subject() { Id = 3, Name = "Biology" },
            new Subject() { Id = 4, Name = "Literature" }
        };
    }
    public static Domain Instance { get { return instance; } }
    public IList<Subject> Subjects { get; set; }
}

Ahora sí el controlador de Subject puede manejar el método Index. Cambio enlaces en la vista que me agregó el wizard. Los cambio de:

a que usen la propiedad Id como clave primaria:

Este es el resultado:

Creé entonces otras vistas, para los otros métodos del controlador Subject. Seguí usando el wizard de Visual Studio “Add View … “:

Me encontré que me faltaban algunas acciones. Escribí una nueva:

public ActionResult Edit(int id)
{
    var model = this.subjects.Where(s => s.Id == id).FirstOrDefault();
    return View(model);
}

con tests! ;-)

[TestMethod]
public void GetSubjectForEdit()
{
    IList<Subject> subjects = GetSubjects();
    SubjectController controller = new SubjectController(subjects);
    ActionResult result = controller.Edit(1);
    Assert.IsNotNull(result);
    Assert.IsInstanceOfType(result, typeof(ViewResult));
    ViewResult viewResult = (ViewResult)result;
    Assert.IsInstanceOfType(viewResult.ViewData.Model, typeof(Subject));
    Subject model = (Subject)viewResult.ViewData.Model;
    Assert.AreEqual(1, model.Id);
    Assert.AreEqual("Mathematics", model.Name);
}

Curiosamente, detecté un test “malo”. Yo había escrito en test AddSubject:

Assert.IsTrue(subjects.Any(s => s.Name == "Chemistry"));
Assert.AreEqual(4, subject.Id);

Pero el nuevo Id debería dar 5 (mi lista usada en los tests tiene 4 temas predefinidos (“subjects”)):

Assert.IsTrue(subjects.Any(s => s.Name == "Chemistry"));
Assert.AreEqual(5, subject.Id);

Arreglé el código y la acción del controler, ejecuté la aplicación web, y voila! Todo funcionó.

Puntos principales:

- Estoy usando un dominio en memoria.

- Las vistas se ejecutan sobre las acciones YA probadas con tests

No hay capa lógica de servicios ni persistencia, aún. Vean que no son necesarias al principio. Voy a agregar una “service layer” como gran refactor. Otros próximos pasos: agregar más clases al dominio (libros en clase Book), escribir esa capa de servicio usando tests, “enchufarla” en los controladores. Y en algún momento agregar persistencia.

Pueden leer posts interesantes sobre TDD sin una base de datos (o agregándola después) escritos por @RonJeffries:

But We Need a Database … Don’t We? | xProgramming.com
See? We Don’t Need a Database … Yet | xProgramming.com

Nos leemos!

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

Escribiendo una Aplicación usando TDD (Parte 4) Alta y Actualización

lopez — Thu, 02 Jun 2011 10:05:00 GMT

Anterior Post
Siguiente Post

En el anterior post, implementé la recuperación de los datos de un Tema de libros. No implementé aún ninguna vista. Estoy escribiendo los tests, e implementando el código del controlador. Es hora de agregar un nuevo Tema (Subject), usando una acción del controlador.

Este fue mi primer test:

[TestMethod]
public void AddSubject()
{
    IList<Subject> subjects = GetSubjects();
    Subject subject = new Subject() { Name = "Chemistry" };
    SubjectController controller = new SubjectController(subjects);
    ActionResult result = controller.Create(subject);
    Assert.IsNotNull(result);
    Assert.IsTrue(subjects.Any(s => s.Name == "Chemistry"));
    Assert.AreNotEqual(0, subject.Id);
}

GetSubjects() es un método ayudante que presenté en el anterior posts. Retorna una lista de temas para tests. Agregué una nueva acción en la clase controladora, para que la solución compile:

public ActionResult Create(Subject subject)
{
    throw new NotImplementedException();
}

Compiló, y el test quedó en rojo:

Entonces, completé el método de acción con el código mínimo para que pase el test:

public ActionResult Create(Subject subject)
{
   subject.Id = this.subjects.Max(s => s.Id);
   subjects.Add(subject);
   return RedirectToAction("Index");
}

Pero quiero redireccionar a la vista de detalle luego de haber dado de alta un item. Agrego el test:

RedirectToRouteResult redirect = (RedirectToRouteResult)result;
Assert.IsTrue(string.IsNullOrEmpty(redirect.RouteName));
Assert.IsTrue(redirect.RouteValues.ContainsKey("id"));
Assert.AreEqual(subject.Id, redirect.RouteValues["id"]);
Assert.IsTrue(redirect.RouteValues.ContainsKey("action"));
Assert.AreEqual("Details", redirect.RouteValues["action"]);

Cambio el código de la acción para que cumpla con el nuevo requerimiento:

public ActionResult Create(Subject subject)
{
    subject.Id = this.subjects.Max(s => s.Id);
    subjects.Add(subject);
    return RedirectToAction("Details", new { id = subject.Id });
}

Ahora, el test en verde:

Seguí un camino similar para escribir el test de actualización de un Tema existente. Esta es la versión actual de ese test:

[TestMethod]
public void UpdateSubject()
{
    IList<Subject> subjects = GetSubjects();
    Subject literature = subjects.Where(s => s.Name == "Literature").FirstOrDefault();
    Subject subject = new Subject() { Name = "SciFi" };
    SubjectController controller = new SubjectController(subjects);
    ActionResult result = controller.Update(literature.Id, subject);
    Assert.IsNotNull(result);
    Assert.IsInstanceOfType(result, typeof(RedirectToRouteResult));
    RedirectToRouteResult redirect = (RedirectToRouteResult)result;
    Assert.IsTrue(string.IsNullOrEmpty(redirect.RouteName));
    Assert.IsTrue(redirect.RouteValues.ContainsKey("id"));
    Assert.AreEqual(literature.Id, redirect.RouteValues["id"]);
    Assert.IsTrue(redirect.RouteValues.ContainsKey("action"));
    Assert.AreEqual("Details", redirect.RouteValues["action"]);
    Assert.IsTrue(subjects.Any(s => s.Name == "SciFi"));
    Assert.AreEqual(literature.Id, subjects.Where(s => s.Name == "SciFi").Single().Id);
}

La acción del controlador:

public ActionResult Update(int id, Subject subject)
{
    Subject toupdate = this.subjects.Where(s => s.Id == id).Single();
    toupdate.Name = subject.Name;
    return RedirectToAction("Details", new { id = id });
}

Todos los tests en verde:

Algunas advertencias: los tests están revisando dos salidas: los cambios en el dominio (por ahor auna simple lista) y los resultados de las acciones (un tema MVC). Debería hacer refactor (seguramente en un futuro post) de la implementación del controlador, para separar las actualizaciones del dominio de los resultados de la navegación. Escribí el ejemplo de esta manera para mostrar cómo hacer refactor más adelante para conseguir una mejor implementación. Mi idea es tener un servicio de manejo de temas, y escribir con tests. Luego usarlo desde el controlador. Debería tambien tratar los casos de actualización de un item inexistente o la creación de un item ya existente.

Otra nota: no puse ninguna vista MVC todavía. Pero ahora ya tengo los tests como para agregarlas con confianza. Cuando las agregue, la conducta esperada del controlador ya estará probada.

Nos leemos!

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

Escribiendo una Aplicación usando TDD (Parte 3) Primer Detalle

lopez — Thu, 31 Mar 2011 09:55:00 GMT

Primer post de la serie
Próximo post de la serie
Anterior post de la serie

Desde el anterior post, he aplicado las sugerencias que dejaron en comentarios @MartinSalias y @theHumanFlag, gracias! (las dejaron en el post en inglés). Primero, renombré la clase Genre a Subject, usando las capacidades de refactoring de Visual Studio:

public class Subject
{
    public string Name { get; set; }
}

Segundo, ahora el controlador recibe y procesa un IEnumerable<Subject>:

public class SubjectController : Controller
{
    private IEnumerable<Subject> subjects;
    public SubjectController()
    {
    }
    public SubjectController(IEnumerable<Subject> subjects)
    {
        this.subjects = subjects;
    }
    public ActionResult Index()
    {
        return View(subjects);
    }
}

Hice los cambios con confianza, gracias a los tests.

Ahora, en este nuevo paso, agregué una acción: dado un Id, obtener el Subject. La propiedad Id agregada en Subjec:

public class Subject
{
    public int Id { get; set; }
    public string Name { get; set; }
}

Escribí el test:

[TestMethod]
public void GetSubjectForDetail()
{
    IEnumerable<Subject> subjects = new List<Subject>()
    {
        new Subject() { Id = 1, Name = "Mathematics" },
        new Subject() { Id = 2, Name = "Physics" },
        new Subject() { Id = 3, Name = "Biology" },
        new Subject() { Id = 4, Name = "Literature" }
    };
    SubjectController controller = new SubjectController(subjects);
    ActionResult result = controller.Details(1);
    Assert.IsNotNull(result);
    Assert.IsInstanceOfType(result, typeof(ViewResult));
    ViewResult viewResult = (ViewResult)result;
    Assert.IsInstanceOfType(viewResult.ViewData.Model, typeof(Subject));
    Subject model = (Subject)viewResult.ViewData.Model;
    Assert.AreEqual(1, model.Id);
    Assert.AreEqual("Mathematics", model.Name);
}

El test no compila. Agregué la acción en el controler:

public ActionResult Details(int id)
{
    return View();
}

El test compila, pero da en rojo. Vamos por el verde:

public ActionResult Details(int id)
{
    var model = this.subjects.Where(s => s.Id == id).FirstOrDefault();
    return View(model);
}

En este punto, tenía dos tests, que daban una lista de Subjects al controlador. Hice refactoreo de los test para separar la creación de la lista. Extraje el método:

private static IEnumerable<Subject> GetSubjects()
{
    IEnumerable<Subject> subjects = new List<Subject>()
    {
        new Subject() { Id = 1, Name = "Mathematics" },
        new Subject() { Id = 2, Name = "Physics" },
        new Subject() { Id = 3, Name = "Biology" },
        new Subject() { Id = 4, Name = "Literature" }
    };
    return subjects;
}

Ahora, el código del test es:

[TestMethod]
public void GetSubjectInDetail()
{
    IEnumerable<Subject> subjects = GetSubjects();
    SubjectController controller = new SubjectController(subjects);
    ActionResult result = controller.Details(1);
    Assert.IsNotNull(result);
    Assert.IsInstanceOfType(result, typeof(ViewResult));
    ViewResult viewResult = (ViewResult)result;
    Assert.IsInstanceOfType(viewResult.ViewData.Model, typeof(Subject));
    Subject model = (Subject)viewResult.ViewData.Model;
    Assert.AreEqual(1, model.Id);
    Assert.AreEqual("Mathematics", model.Name);
}

Todo en verde!

Como siempre, el código está en mi AjCodeKatas Google Project, esta vez en trunk/AppTdd/Step02)

Próximos pasos: más acciones, integrar alguna vista.

Nos leemos!

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

Escribiendo una Aplicación usando TDD (Parte 2) Primera lista

lopez — Fri, 25 Mar 2011 14:48:00 GMT

Siguiente post en esta serie
Anterior post en esta serie

Gracias a un comentario de @MartinSalias, en mi post anterior, elegí para desarrollar este ejemplo un dominio simple: mi biblioteca personal, mis libros. En esta primera iteración de código, quiero listar los temas de los libros: Física, Matemáticas, Biología, Literatura… (similar a los génereos del ejemplo MvcMusicStore de @jongalloway).

Primero, creé una solución ASP.NET MVC 2 (estoy usando Visual Studio 2008) (el código de este post, como siempre, queda en mi AjCodeKatas Google Project, en el directorio trunk/AppTdd/Step01)

Luego, agregué un proyecto de test:

A este proyecto le agregué referencias a System.Web.Mvc and MyLibrary.Web.

Agregué un test:

Limpié el código de la clase generada por el wizard, removiendo código no usado. Quedó:

namespace MyLibrary.Web.Tests.Controllers
{
    using System;
    using System.Text;
    using System.Collections.Generic;
    using System.Linq;
    using Microsoft.VisualStudio.TestTools.UnitTesting;
    [TestClass]
    public class GenreControllerTests
    {
    }
}

Ahora, agregué mi primer test:

        [TestMethod]
        public void GetGenres()
        {
            IList<Genre> genres = new List<Genre>()
            {
                new Genre() { Name = "Mathematics" },
                new Genre() { Name = "Physics" },
                new Genre() { Name = "Biology" },
                new Genre() { Name = "Literature" }
            };
            GenreController controller = new GenreController(genres);
            ActionResult result = controller.Index();
            Assert.IsNotNull(result);
            Assert.IsInstanceOfType(result, typeof(ViewResult));
            ViewResult viewResult = (ViewResult)result;
            Assert.IsInstanceOfType(viewResult.ViewData.Model, typeof(IList<Genre>));
            Assert.AreSame(genres, viewResult.ViewData.Model);
        }

La idea del test: crear el controlador, alimentarlo de una lista de temas, y luego invocar su acción Index. Hecho eso, controlar el resultado. A esta altura, el código no compilaba: el controlador no existía, no había clase Genre. Así que escribí esas clases. La clase Genre, en el directorio Model del proyecto MyLibrary.Web:

    public class Genre
    {
        public string Name { get; set; }
    }

Un controlador simple GenreController (agregado con click derecho sobre el directorio Controllers):

El wizard produjo este código:

    public class GenreController : Controller
    {
        //
        // GET: /Genre/
        public ActionResult Index()
        {
            return View();
        }
    }

Lo modifiqué para que tenga el constructor que necesito en el test:

    public class GenreController : Controller
    {
        public GenreController()
        {
        }
        public GenreController(IList<Genre> genres)
        {
        }
        public ActionResult Index()
        {
            return View();
        }
    }

Noten que mi intención es compilar el test, no que fuencione: la lista de temas no es usada por esta primer implementación de controlador. Con todos estos cambios, pude compilar la solución y ejecutar el test:

El resultado:

El problema:

Como esperaba. Esto es parte del ciclo TDD: compilar, rojo, y ahora, hay que ir por el verde.

Cambié el controlador (su interfaz ya estaba completa):

    public class GenreController : Controller
    {
        private IList<Genre> genres;
        public GenreController()
        {
        }
        public GenreController(IList<Genre> genres)
        {
            this.genres = genres;
        }
        public ActionResult Index()
        {
            return View(genres);
        }
    }

Y ahora, el resultado es:

Triunfo de la mente sobre la materia! ;-)

Ahora, es tiempo de refactoring. Bien, no tengo mucho para hacer ahora (me llega un comentario en mi post en inglés de @MartinSalias, sugiriendo cambios en la nomenclatura, bien, quedará para el próximo paso). Podría mejorar alguna variable, nombre. La principal pieza faltante: la vista. Nota: el controlador no está preparado, aún, para ser consumido por una vista. No hay quien le provea los temas en ejecución. En el test, usé un constructor que se los provee, pero ASP.NET MVC crearía la instancia del controlador usando el constructor sin parámetros.

Próximos pasos: mejorar el controlador para usar una vista, algunas acciones CRUD con tests, y vistas.

Podrían preguntar: ¿dónde está el repositorio de los temas? ¿dónde están los libros? ¿y la base de datos? ¿y la capa de servicios (service layer)? ¿separación del dominio? Ok, son todas preguntas válidas y temas a tratar. Pero mi idea es mostrar, de forma incremental, con TDD, cómo podemos ir agregando todo eso a medida que aparezcan más requerimientos y especificaciones. Quiero que cada cosa que se agregue provenga del proceso de escribir test (ya sea de la especificación del test, o de la etapa de refactoring). Como escribí en mi anterior post, esta es una clase de aproximación arriba-abajo (top-down). En este caso, el dominio es simple, así que comienzo desde el tope de la presentación. Luego de este ejemplo simple, a desarrollar en varios post, cambiaré a un dominio menos simple. En ese caso, comenzaré por construir por tests al propio dominio, en lugar de la presentación.

Nos leemos!

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