Talangprogrammet: Funktionellt basflöde i sprint 1

februari 21, 2013

Med stödet från sprint 0 i ryggen tog vi oss an första sprinten där vi faktiskt skulle leverera funktionalitet och innehåll. Temat för denna sprint bestämdes till “Funktionellt basflöde”, vilket vi kom fram till innebar att det skulle gå att skapa, ändra och visa konsultprofiler.

Det här är en statusrapport från sprint 1 (första sprinten var sprint 0).

Eftersom målet vid tillfället för sprintdemot är att ha en produkt som, om kunden skulle önska, går att släppa i produktion med en gång är det viktigt att teamet slutför de stories de åtagit sig i alla avseenden. Inga knappar som inte gör något, “dynamiska element” som är statiska för att backenddelar saknas eller ofullständig design tillåts. Det medförde att vi direkt fick djupdyka på i princip alla områden; CSS och responsive design, webbläsarkompatibilitet, MongoDB och dataaccesslager, etc.

Kortfattat om sprinten

Under början av sprinten gick därför en hel del tid åt till att (förutom att studera inför det WCF-certifikat vi skulle ta samma vecka) sätta upp bra grunder för HTML/CSS/Javascript och databaskommunikation som vi sedan ska kunna återanvända och bygga vidare på. Vi skapade en masterpage för att samla de delar som är gemensamma för de olika sidorna, lade upp Module pattern för Javascript och abstraherade MongoDB bakom ett generiskt IRepo med CRUD-funktionalitet.

Backendmässigt låg mycket fokus på att få kod både i MVC4-kontrollerna och dataaccesslagret testbart med enhetstester. Genom vår handledare och utbildare Tobias Hasslebrant som är kung på området fick vi lära oss om RhinoMock, IOC och Ninject, vilket visade sig mycket användbart tillsammans med MVC4.

Enhetstestning av MVC4-kontroller

Ett exempel: vår ProjectsController. ProjectsController används för att skapa projektteam av konsult-CVn som kan presenteras som förslag till en kund. Den behöver därför tillgång både till konsultprofiler och projekt från databasen. För att kunna skriva enhetstester som testar logiken endast i själva kontrollern måste vi kunna mocka dess beroenden. Vi skickar därför in dessa i konstruktorn enligt nedan.

    
public ProjectsController(IRepo<Project> projRepo,
                          IRepo<ConsultantProfile> consRepo)
{
    ...
}

Det kan tyckas problematiskt eftersom MVC4 konstruerar Controllers automatiskt, och vi därför inte har kontroll över argumenten till konstruktorerna. Ninject löser lyckligtvis detta på ett snyggt sätt; det finns en NinjectHttpModule som använder en Ninject-kernel för att instansiera eventuella objekt som behövs i kontrollernas konstruktorer. Man konfigurerar denna IKernel i en PreApplicationStartMethod, se nedan.

    
private static void RegisterServices(IKernel kernel)
{
    var mongoConnectionstring =
         Config.GetSaltedMongoConnectionString();
    kernel.Bind<IRepo<ConsultantProfile>>().ToMethod(
         w => new MongoRepo<ConsultantProfile>(mongoConnectionstring));
    kernel.Bind<IRepo<Project>>().ToMethod(
         w => new MongoRepo<Project>(mongoConnectionstring));
}

När Ninject hittar en Controller som tar ett IRepo<ConsultantProfile/Project> i konstruktorn, instansierar den automatiskt ett objekt enligt funktionen i ToMethod() som den skickar in. I enhetstesterna för kontrollern blir det sedan lätt att mocka dessa beroenden med hjälp av RhinoMock:

    
[Test]
public void SomeTest()
{
    var consultantRepo =
        MockRepository.GenerateStub<IRepo<ConsultantProfile>>();
    var projectRepo =
        MockRepository.GenerateStub<IRepo<Project>>();
    // add return values for used methods in mocked repositories
    var controller = new ProjectsController(projectRepo,
                                            consultantRepo);
    // call actions on controller and assert
    // methods in mocks were called
}

 

Sammanfattning

Dessa enhetstester i kombination med integrationstester i Selenium har redan under denna sprint hittat ett antal edge cases och feltänk som med stor sannolikhet hade kunnat leta sig ut i produktion om vi inte hade haft dem. Under sprinten har det också blivit mycket tydligt vad skillnaden på enhetstest och integrationstest är. Enhetstester testar endast en mycket isolerad del av koden, medan integrationstesterna testar hela flödet (“agerar en användare”, se video nedan).

Efter en något långsam första vecka (storymässigt) lyckades vi ändå få alla stories klara i tid för sprintdemot fredagen den 15 februari. Med basflödet på plats ser nu läget ljust ut för nästa sprint, där vi kommer fokusera på att produktionssätta webbapplikationen publikt så att den kan börja användas även om all funktionalitet inte är på plats – en viktig pelare i agil utveckling.

Fortsätt att läsa Affärsvärde genom refaktorering? - del 3 i Talangprogrammets bloggserie.