Du burde kunne loade projektet i din favorit editor. Et par noter om opbygningen af mappestrukturen

• To mapper - src og lib. src indeholder de to projekter, lib indeholder 3dje parts frameworks.

• To projekter - Behaviour indeholder mine specifikationer og alt dokumentation. Domain indeholder interfaces og implementation.

For at køre integrationstestene og iøvrigt lege med data, skal følgende trin følges:

• Installation af en PostGRE sql (jeg kører 8.3, men burde virke på tidligere versioner).
• Ændring af connection-stringen i begge projekter til at pege på en ny tom database.

God fordøjelse - og husk Rom blev ikke bygget, men drukket på en dag.

De fleste har nok hørt om IoC - Inversion of Control. Egentlig handler det meget om at bryde afhængigheder, ved at bruge DI (Dependency Injection). Dvs. at istedet for at to klasser er direkte afhængige af hinandens implementation - er de alene afhængige af hinandens interface. IoC udmærker sig ved at gøre det muligt først at lave koblingen run-time - og for de noget mere avancerede scenarier give mulighed for at udskifte konkrete implementationer run-time.

Vi bruger IoC via Windsor Castle - et fantastisk Framework, som virkelig gør det nemt at opsætte afhængigheder (kræver at man kan stave rigtigt i sin XML… men ellers rimelig nem at sætte op). I princippet kan vi på den samme installation køre med forskellige opsætninger for to forskellige brugere… måske et lidt tænkt scenarie, men alligevel meget kraftfuldt.

Den anden halvdel af min kombo er MVP - Model View Presenter. Her går det ud på at separere design fra logik via DI. Ideen er at man indsætter en Mediator (presenter) imellem view og model (typisk en domain service eller direkte på et domæneobjekt). Dvs. at presenteren får kald fra viewet, når brugeren interagerer og formidler det videre til modellen, som så kan lave call-backs osv. View og model kender ikke hinanden - kun presenteren kender begge. MVP kan godt virke lidt uelegant, fordi viewet initierer presenteren med sig selv som argument i constructoren i de fleste implementationer.

Det er muligt at trække afhængighederne fra MVP ud i en noget IoC lignende med en PresenterService.CreateViewPresenter()-noget, men så er vi blot afhængige af en ny klasse.

Nu kommer komboen så. Via IoC udleder vi den konkrete implementation af presenteren direkte og udleder de konkrete implementation af model og view - altsammen run-time.

Okay - det var mange termer på en gang - først den ‘gammeldags’ (lettere modificeret til noget a’la ServiceLocator) implementation af MVP:

…
ISomeView _view = new SomeView();
_view.Show();
…

public class SomeView : Window, ISomeView
{

private ISomePresenter presenter
public SomeView()
{

InitializeComponent();
presenter = PresenterService.GetSomePresenter(this);

}
protected override OnInit()
{

presenter.Init();

}

…
}

public class SomePresenter : ISomePresenter
{

private ISomeView _view;
private ISomeService _service;

public SomePresenter(ISomeView view)
{

_view = view;
_service = ServiceService.GetSomeService();

}
public void Init()
{

do some wiring here…

}
…

}

public class SomeService : ISomeService
{

public SomeService(){}
…

}

Ingen direkte koblinger - dejligt - men der er mange ekstra klasser i spil. Det er nemt at teste hver af dem med mocking, men det virker uelegant.

Nu til vores nye løsning:

…
WindsorContainer _container = new WindsorContainer();
ISomePresenter _presenter = _container.Resolve<ISomePresenter>();
_presenter.View.Show();
…

public class SomeView : Window, ISomeView
{

public SomeView()
{

InitializeComponent();

}

}

public class SomePresenter : ISomePresenter
{

public SomePresenter(ISomeView view, ISomeService service)
{

Do some wiring

}

}

public class SomeService : ISomeService
{

public SomeService(){}
…

}

Hvis det ikke er mere elegant - så må du kalde mig Herrr YAGNI for al evighed. Ooh - og eftersom vi bruger WPF… så kan designet ligge i ‘løse’ XAML-filer, som vi compiler run-time… og vi kan dermed skifte dem imens applikationen kører. Okay - træerne gror ikke ind i himlen. Der er en pris at betale for den _meget_ løse kobling… performance may suffer. Men det vil tiden vise, når vi får de første implementationer op at køre.

Inline dokumentation er nu engang så meget lettere at vedligeholde, og den er så dejlig tæt ved hånden. Iøvrigt en af de store fordele ved Scrum - det anbefales at holde dokumentationen på et minimum. BDD foreskriver 25-200 siders dokumentation i papirform - og 200 sider er for enorme systemer.

Jeg lægger applikationen op, når jeg lige pusse-nusset lidt om den. På nuværende tidspunkt kan jeg kodemæssigt gemme alle relevante data fra mine aggregater i en PostGRE database via NHibernate. Jeg kan tilføje bilag til en finanskladde, og tilføje kladdelinjer til bilag udover hvad der er nævnt i de forrige indlæg.

I mine næste indlæg vil jeg gå lidt mere i dybden med NHibernate - jeg er ikke 100% tilfreds med Ayende’s dokumentation. Nogle steder er den meget indforstået og andre steder er den lidt out-of-date (jeg ved det… 3.5 er stadig i RC, men meget af det har ikke ændret sig synderligt i de seneste versioner).

Der har dog allerede nu meldt sig en bug på banen. Et uheldigt medlem af udviklerstaben har misbrugt designet. Det vil sige, han har sådan set blot anvendt interfacet og dermed fundet et enkelt punkt, hvor designet ikke helt holdt vand. Problemet findes i interfacet til IGeneralLedger:

using System;
using System.Collections;

public interface IGeneralLedger
{

void AddAccount(ILedgerAccount account);
void DeleteAccount(ILedgerAccount account);
IDictionary Accounts{get;}

}

Problemet er måske ikke helt indlysende. Det er et forholdsvist enkelt design - og det skal vise sig at udviklerens dovenskab er problemet. For at gøre det enkelt (for ham selv) har han valgt at publicere IDictionary for Accounts. Det er faktisk meget uheldigt, fordi han dermed har publiceret indgange til data, som ikke er omfattet af test - og dermed må betragtes som en bug. For de læsere, som stadig ikke er helt med:

…
IGeneralLedger _generalLedger = new GeneralLedger();
…
_generalLedger.Accounts.Clear();
…

Heldigvis blev problemet hurtigt opdaget af brugeren, så vi kan nå at ændre interfacet inden der er kommet alt for meget funktionalitet i spil:

using System;
using System.Collections;

public interface IGeneralLedger
{

void AddAccount(ILedgerAccount account);
void DeleteAccount(ILedgerAccount account);
int AccountCount{get;}
bool ContainsAccount(int accountId);

}

Som altid er der et par designvalg inde over. Jeg kunne have valgt at indføre en konvention om, hvilke funktioner udviklere måtte have ‘lov’ til at bruge fra IDictionary’et… Dels giver det sig selv, at det ville blive uoverskueligt, hvis der var flere af den slags konventioner… og chancen for fejl ville være overhængende.

En rigtig grim og dårlig løsning ville være at lave min egen version af IDictionary, som nedarver fra Dictionary<int,ILedgerAccount>, override funktionerne, som ville give mig problemer og så kaste exceptions, hvis de blev brugt. I et svagt øjeblik, kunne man godt blive fristet af den løsning, hvis applikationen var i produktion og den samlede kodemasse var stor, men det er et design-smell, der lugter så grimt, at det under alle omstændigheder er en ulykke der venter på at ske.

Alternativt kunne jeg have valgt at lave mit eget wrapper-object omkring noget, der implementerer IDictionary, og så publicere (mappe) de funktioner, som jeg har brug for, og ville gøre det nemt senere at implementere alle de andre metoder jeg (højst sandsynligt) får brug for. Men i den begrundelse, ligger samtidig begrundelsen (pun intended) for hvorfor jeg ikke har valgt det… YAGNI.

Så har jeg valgt at publicere Contains alene med en int-værdi. Jeg kunne have valgt at lave den med en ILedgerAccount og så slå op om den’s Id lå i samlingen. Det har jeg valgt ikke at gøre ud fra flere hensyn: For det første gør det det uklart for andre udviklere, hvad den slår op i og med hvad - og hvad formålet med funktionen er. For det andet kunne Udvikleren (med rette) være bekymret for hvad der sker, hvis der er logisk lighed men ikke referentiel lighed osv. osv. Intentionen med kode skal være nem at læse - også ud fra interfaces.

Her var jeg heldig, at problemet blev opdaget forholdsvis hurtigt - hvis det havde været tæt på release, ville gode dyr have været rådne. Det var under testen af første iterations release, at fejlen blev fanget af en uforsigtig udvikler. Men det viser meget godt styrken ved iterativ udvikling. De fleste fejl bliver fanget imens det stadig er forholdsvis billigt at rette. Her var det fire linjers kode i min test-suite og 8 i min produktionskode. Prøv for tankeeksperimentets skyld at overveje hvor dyrt det ville have været med en fejl i kontoplanskoden i et fuldt ERP-program…

Samtidig har jeg stiftet nærmere bekendtskab med nogle gode værktøjer. Min definition af gode værktøjer er, at de gør mit arbejde lettere. Det kan lyde banalt, men et værktøjs rolle er ikke at ændre på min arbejdsgang eller introducere mig for nye arbejdsgange. De skal lette eller understøtte dem jeg allerede har. Nedenfor vil jeg nævne mine favoritter indenfor forskellige kategorier.

Vinderen for bedste overall test-suite er NUnit. Det er ikke uden grund, at langt de fleste TDD’ere bruger den. Det virker bare - og med tilføjelsen af Rhino Mocks er jeg nået rigtig langt. Jeg har stadig ikke nået at få stiftet bekendtskab med White - men jeg vender tilbage, når jeg får det testet. Det er bygget ovenpå Rhino og NUnit - og har sin force inden for testning af UI (og mere specifikt WPF). Jeg har været kort omkring NMock2, men kombinationen af at dens syntax er lidt knudret og tung samt at den ikke er typestærk gør, at Rhino løber med sejren. (Og en irriterende fejl i seneste version (2.0.0.44), som kaster exceptions ved mocks af interfaces med generiske metoder.

Vinderen for bedste utility er Reflector. Jeg har den konstant kørende i baggrunden som en udvidet hukommelse til at huske metodekald og obskure nedarvninger. ReSharper er jeg endnu ikke blevet dus med. Jeg er ikke i tvivl om at det er et fantastisk værktøj, men det kræver tid at vænne sig til og udnytte. Jeg er stadig i irritationsfasen, hvor den har ‘overtaget’ mine keyboard short-cuts i VS. Jeg håber på, at vi kan få det som et tema på arbejde med “de 7 taste-tryk, der forbedrer min arbejdshastighed med 50% ™”.

Og O/RM… NHibernate. Jeg har kun skrabet i overfladen af dette omfattende værktøj - men kan indtil videre kun sige… wow. Jeg har været omkring SubSonic og LiNQ. I det felt er NHibernate lysår foran. Lækkert, lækkert værktøj. Lidt knudret at sætte op og syntaxen er heller ikke 100% strømlinet, men hvad den taber på syntaxen mere end gør den op for i performance, vedligeholdelse og opsætningsmuligheder.

Nogle hårde, men lærerige måneder, som fundementalt har ændret min holdning og tilgang til kodning. Alt er ikke lyserødt, men fremtiden virker mere overskuelig…

using System;
using Domain.Interfaces;
using System.Collections.Generic;
using System.Collections;

public class GeneralLedger:IGeneralLedger
{

private Dictionary _accounts;
public GeneralLedger()
{

_accounts = new Dictionary();

}
public void AddAccount(ILedgerAccount account)
{

if (account == null)
{

throw new ArgumentNullException(”Null account supplied”);

}
if (!account.IsValid)
{

throw new ArgumentException(”Invalid account”);

}
if (_accounts.ContainsKey(account.AccountId))
{

throw new ArgumentOutOfRangeException(”AccountId is already present”);

}
_accounts.Add(account.AccountId,account);

}
public void DeleteAccount(ILedgerAccount account)
{

if (account == null)
{

throw new ArgumentNullException(”Null account supplied”);

}
if (!_accounts.ContainsKey(account.AccountId))
{

throw new ArgumentOutOfRangeException(”AccountId is not present”);

}
_accounts.Remove(account.AccountId);

}
public IDictionary Accounts
{

get{return _accounts;}

}

}

Man kan med rette sige, at mit første eventyr ud i BDD har været forholdsvis simpelt. Det er dog ikke en begrænsning for at kunne se styrken i paradigmet. Jeg har implementeret de første to User Stories i programmet - og brugeren har sagt god for det. Brugeren har noget at vise sin chef (okay, han bliver sikkert ikke voldsomt imponeret, men bare vent til den næste iteration…) - fix og færdig funktionalitet. Programmet kan det, vi har bedt det om at kunne. Det er en af de ting, jeg er mest begejstret for i BDD - ting opfører sig som man har specificeret. Og hvis de ikke gør, så vil en af den række specifikationstests afsløre det ved næste gennemkørsel af test-suiten.

Koden er stort set selv-dokumenterende. Indtil videre har jeg ikke behøvet skrive kommentarer til koden. Ikke at det er en hindring for at gøre det - jeg bør gøre det senere, men jeg har ikke tænkt mig at trætte dine øjne med det - kodeeksemplerne er lange nok i forvejen. Nu kan man vælge at tro mig eller lade være, men ovenstående kodestump tog mig under 5 minutter at skrive. Der er ikke et gram unødig kode. Der er ingen bloat. Der er lige nøjagtig nok kode til at brugeren er glad, hvilket gør mig glad (skizophreni er nu en underlig ting, at skulle forholde sig til).

Men nogen vil måske sige, at det er totalt overkill, at jeg har brugt over 4 gange så mange linjer på test/dokumentation/UL som på kodelinjer i implementationen. Jeg er ikke enig. Min påstand er, at den x5 faktor med antal linjer stadig er mindre end hvis jeg var startet med at implementere fra starten uden User Stories, fordi jeg så ville have skullet ændre ting midt vejs, slette unødig kode, som virkede som en god ide på det tidspunkt.

Og ikke mindst, jeg slipper for at dokumentere kode, som ville have været mere knudret, fordi jeg uanset mine gode intentioner ville være startet med at løse 8 forskellige funtionalitetskrav på en gang (”Når nu jeg alligevel er ved at lave properties… så kan jeg ligeså godt oprette de her tre andre, som jeg sikkert får brug for… ooh, og alle ved at man skal bruge en IsDirty…) og det ville have været starten på bloat. Hvis det ikke er et krav fra brugeren - så er det per definition bloat. Brugeren har talt - og han sagde at det vigtigste for ham var at han ville kunne oprette og slette finanskonti. Ville det så ikke være fjollet at begynde at lave et avanceret logging system? Ja, skåret ud i pap, men det er hele essensen i, hvorfor de fleste projekter ender på de evige bit-marker. Det er brugeren der betaler - og jo hurtigere han kan se, at han får det han har bedt om - jo mere villig er han til at betale.

Oh ja, og det bedste af det hele? Jeg er ikke det mindste i tvivl om, at min kode virker, fordi jeg har ikke skrevet noget kode, som ikke er testet. Jeg har rent faktisk en code-coverage på 100%!

Og for så at tage den ‘teoretiske’ tilgang - designet bør være uafhængig af den faktiske implementation, fordi man så kan skifte implementationen uden at man skal lave alt det andet om. Jeg har sat teoretisk i situationstegn, fordi det i høj grad også er summen af erfaringer gjort i den virkelige verden, som ligger til grund for teorierne på dette punkt.

Mit næste problem var efter, jeg stiftede bekendtskab med unit-test. Begreber som black-box, white-box, mocking og stubs er intellektuelt svære at koble sammen, når man ser dem i en kontekst, hvor man er fokuseret på at teste implementationen. Hvornår man anvender den ene i forhold til den anden - hvornår det giver mening at teste en metode særskilt, og hvorfor det overhovedet er interessant, når nu outputtet er resultatet af en string.Format(”{0}.{1}”,param1,param2).

Men lad os lade EconomyDeluxe tale som eksempel på, hvorfor mocking og interfaces går hånd i hånd, når adfærdsspecifikationer skal laves. Først skal jeg have lavet nogle interfaces for at kunne lave mine tests, som beskrevet i det forrige indlæg. Det virker rimelig klart at vi gerne vil vide om en FinansKonto er gyldig (IsValid) og den skal have et unikt nummer:

using System;

public interface ILedgerAccount
{

int AccountId{get;}
bool IsValid{get;}

}

Første anke kunne være, hvorfor jeg anvender en int som unik nøgle, og ikke en GUID; og hvorfor jeg ikke adskiller Id’et fra en kontonummeret, så jeg kunne have mulighed for at bruge en string - og hvad med, når det skal gemmes i en db. Svaret er faktisk rimelig simpelt - jeg ved ikke endnu om det er nødvendigt. YAGNI og KISS er to patterns som jeg er meget tilhænger af. Jeg er ved at beskrive adfærden - og hvad FinansBalancen skal vide om FinansKonto, for at kunne lave adfærdsspecifikationen - hvorvidt FinansKonti overhovedet skal gemmes i en database, har jeg slet ikke overvejet på nuværende tidspunkt.

FinansBalance er næste offer - vi ved at vi gerne vil kunne tilføje og slette FinansKonti. Og vi vil gerne kunne tælle hvor mange FinansKonti, der ligger i FinansBalancen - og sidst men ikke mindst vil vi gerne kunne finde ud af om en FinansKonto’s AccountId allerede er tilføjet - vi prøver:

using System;
using System.Collections;

public interface IGeneralLedger
{

void AddAccount(ILedgerAccount account);
void DeleteAccount(ILedgerAccount account);
IDictionary Accounts{get;}

}

Igen har vi en situation, hvor mine valg måske ikke er umiddelbart gennemskuelige. Det ligger nok i kortene at vi skal have noget liste-agtigt at slå op i og tælle på. Grunden til valget af IDictionary er at det er den mest letvægts standardimplementation, som opfylder mine krav - havde jeg valgt IEnumerable (som er mest letvægts), mangler jeg både Count, Add og Delete - så jeg ville skulle lave disse funktioner særskilt - hvilket ville gøre IEnumerable et dårligt valg. ICollection (som er den næste i rækken af liste-implementationer) ville have givet mig Count - men jeg mangler stadig Add og Delete. Og så når vi til IDictionary eller IList - som har alt den funktionalitet, som jeg skal bruge her og nu. IDictionary vinder fordi det i implementationen ikke er muligt at tilføje den samme nøgle til samlingen - hvilket er en god sikkerhed i mit tilfælde. Opslag på nøgleværdien er desuden billigt, fordi jeg kan slå op i nøgleværdierne alene og jeg er ikke afhængig af at skulle sammenligne objekter på property-niveau.

Og til sidst grunden til at jeg ikke sætter returtypen til Dictionary? Fordi jeg igen ikke ved nok til at vælge en implementation, og specifikationen skal stadig være uafhængig - om jeg anvender HashTable eller SortedList osv. er ligegyldig for specifikationen, jeg skal bare vide at jeg har en Count, en Contains, en Delete og en Add metode til rådighed. Men hov, hvorfor kan jeg så tillade mig at bruge void i metoderne? Hvad nu, hvis jeg senere finder ud af, at fx jeg gerne vil have nøglen tilbage? Hvis det bliver nødvendigt - ændrer jeg retur-typen. Det får ingen betydning for den eksisterende implementation, da det alene er en tilføjelse. I den eksisterende kodebase kan jeg med sindsro ignorere returværdien, fordi den ikke er nødvendig i den del af implementationen.

Lad os se, hvad det giver os, når vi skal udbygge GeneralLedgerBehaviour:

using System;
using NUnit.Framework;
using NMock2;

[TestFixture()]
public class GeneralLedgerBehaviour
{

private Mockery _mockery;
private IGeneralLedger _generalLedger;
private ILedgerAccount _ledgerAccount;

[SetUp()]
public void setupBehaviour()
{

_generalLedger = new GeneralLedger();
_mockery = new Mockery();
_ledgerAccount = _mockery.NewMock<ILedgerAccount>();

}

#region [UserStory: Adding LedgerAccounts to GeneralLedger]
[Test()]
public void shouldAddLedgerAccountOnAddWithValidLedgerAccount()
{

Expect.Once.On(_ledgerAccount).GetProperty(”IsValid”).Will(Return.Value(true));
Expect.AtLeastOnce.On(_ledgerAccount).GetProperty(”AccountId”).Will(Return.Value(10));
_generalLedger.AddAccount(_ledgerAccount);
Assert.AreEqual(1,_generalLedger.Accounts.Count);
Assert.IsTrue(_generalLedger.Accounts.Contains(10));

}

[Test()]
[ExpectedException(typeof(ArgumentException))]
public void shouldThrowExceptionOnAddWithInvalidLedgerAccount()
{

Expect.Once.On(_ledgerAccount).GetProperty(”IsValid”).Will(Return.Value(false));
_generalLedger.AddAccount(_ledgerAccount);

}

[Test()]
[ExpectedException(typeof(ArgumentNullException))]
public void shouldThrowExceptionOnAddWithNullLedgerAccount()
{

_ledgerAccount = null;
_generalLedger.AddAccount(_ledgerAccount);

}

[Test()]
[ExpectedException(typeof(ArgumentOutOfRangeException))]
public void shouldThrowExceptionWhenAddingLedgerAccountWithIdenticalId()
{

Expect.Exactly(2).On(_ledgerAccount).GetProperty(”IsValid”).Will(Return.Value(true));
Expect.AtLeastOnce.On(_ledgerAccount).GetProperty(”AccountId”).Will(Return.Value(10));
_generalLedger.AddAccount(_ledgerAccount);
_generalLedger.AddAccount(_ledgerAccount);

}
#endregion

#region [UserStory: Deleting LedgerAccounts from GeneralLedger]
[Test()]
public void shouldDeleteSuppliedExistingLedgerAccount()
{

Expect.Once.On(_ledgerAccount).GetProperty(”IsValid”).Will(Return.Value(true));
Expect.AtLeastOnce.On(_ledgerAccount).GetProperty(”AccountId”).Will(Return.Value(10));
_generalLedger.AddAccount(_ledgerAccount);
_generalLedger.DeleteAccount(_ledgerAccount);
Assert.IsFalse(_generalLedger.Accounts.Contains(_ledgerAccount.AccountId));

}

[Test()]
[ExpectedException(typeof(ArgumentOutOfRangeException))]
public void shouldThrowExceptionWhenDeletingNonExistingLedgerAccount()
{

Expect.AtLeastOnce.On(_ledgerAccount).GetProperty(”AccountId”).Will(Return.Value(10));
_generalLedger.DeleteAccount(_ledgerAccount);

}

[Test()]
[ExpectedException(typeof(ArgumentNullException))]
public void shouldThrowExceptionWhenDeletingNullLedgerAccount()
{

_ledgerAccount = null;
_generalLedger.DeleteAccount(_ledgerAccount);

}
#endregion

}

Meget let og elegant, hvis jeg selv skal sige det. Den eneste forudsætning for at ovenstående vil kompilere er, at jeg laver en klasse som hedder GeneralLedger, som implementerer IGeneralLedger. Hvis jeg på et tidspunkt finder på at lave TheNewAndImprovedGeneralLedger, skal jeg kun skifte en enkelt reference i SetUp-metoden for at teste om den overholder mine specifikationer. I min næste post vil jeg vise en implementation, som overholder min specifikation.

Oprettelse af FinansKonti i KontoPlan

Som en Bogholder
Vil jeg gerne kunne tilføje en FinansKonto til Kontoplanen
Så jeg opnår mulighed for at lave FinansPosteringer på den og kan følge virksomhedens indtægter og udgifter.

Accepteres når:
Under forudsætning af en gyldig FinansKonto
som ikke eksisterer i KontoPlanen.
Når jeg tilføjer den til KontoPlanen
Skal antallet af FinansKonti stige med 1
og KontoPlanen skal indeholde FinansKontoen.

Under forudsætning af en ugyldig, allerede eksisterende eller FinansKonto med værdien null
Når jeg tilføjer den til KontoPlanen
Skal der kastes en Exception.

Sletning af FinansKonti fra KontoPlan

Som en Bogholder
Vil jeg gerne kunne slette ubrugte FinansKonti fra KontoPlanen
Så jeg opnår en strømlinet KontoPlan og kan fjerne fejloprettede FinansKonti.

Accepteres når:
Under forudsætning af en gyldig FinansKonto
Når jeg fjerner den fra KontoPlanen
Skal antallet af FinansKonti falde med 1
og KontoPlanen skal ikke længere indeholde FinansKontoen.

Under forudsætning af en ugyldig eller FinansKonto med værdien null
Når jeg fjerner den til KontoPlanen
Skal der kastes en Exception.

Som et designvalg, har jeg valgt at FinansKonti skal have et unikt nummer. Min erfaring (og jeg har snakket med brugeren… mig, og han er enig) er at bogholdere ikke rigtig kan holde styr på FinansKonti med samme kontonummer.

De nævnte User Stories er også placeret på en statisk side her (på engelsk som vanligt) - hvor de vil blive opdateret og udviklet efterhånden som projektet udvikler sig. Der er selvfølgelig en lang række funktionalitet, jeg har planer om, men de her har den største forretningsværdi for mig nu (de fleste andre afhænger nemlig af dem her). For at påbegynde min iteration (jeg kører efter en tillempet Agil udviklingsmetode som jeg kalder SuperScrumLightXP NuMedExtraKaffe eller SSL NMEK - udtales ssschmæk) er det nu tid til at bore lidt i mine User Stories. Hvad forventer jeg af systemets adfærd - hvornår skal det beskytte mig imod mine egne tåbeligheder, og hvilke krav skal jeg stille til returdata?

Endelig er det tid til lidt kode-gymnastik - vi skal have lavet nogle tests adfærdsspecifikationer. Jeg har valgt at de ovenstående User Stories skal håndteres af GeneralLedger, så i gang med kodeklaskeriet.

using System;
using NUnit.Framework;

[TestFixture()]
public class GeneralLedgerBehaviour
{

#region [UserStory: Adding LedgerAccounts to GeneralLedger]
[Test()]
public void shouldAddLedgerAccountOnAddWithValidLedgerAccount(){}

[Test()]
[ExpectedException(typeof(ArgumentException))]
public void shouldThrowExceptionOnAddWithInvalidLedgerAccount(){}

[Test()]
[ExpectedException(typeof(ArgumentNullException))]
public void shouldThrowExceptionOnAddWithNullLedgerAccount(){}

[Test()]
[ExpectedException(typeof(ArgumentOutOfRangeException))]
public void shouldThrowExceptionWhenAddingLedgerAccountWithIdenticalId(){}
#endregion

#region[UserStory: Deleting LedgerAccounts from GeneralLedger]
[Test()]
public void shouldDeleteSuppliedExistingLedgerAccount(){}

[Test()]
[ExpectedException(typeof(ArgumentOutOfRangeException))]
public void shouldThrowExceptionWhenDeletingNonExistingLedgerAccount(){}

[Test()]
[ExpectedException(typeof(ArgumentNullException))]
public void shouldThrowExceptionWhenDeletingNullLedgerAccount(){}
#endregion

}

Det fantastiske (?) er at jeg endnu ikke har skrevet et gram kode i min løsning, men jeg har allerede beskrevet specifikationen til hvordan jeg forventer at mit domain opfører sig. Jeg ville i princippet kunne udlevere denne stump kode og en kop kaffe, og så ville en hvilken som helst kodekarl kunne implementere det. Okay - måske ville det hjælpe lidt, hvis jeg skriver inde i min kode, hvad jeg forventer, men på det tidspunkt, er vi så småt begyndt at snakke om vores løsning - og det reserverer jeg til mit næste indlæg.

Det første skridt på vejen er at få skabt et Ubiquitous Language, UL (ikke-tolkbart sprog, dvs. alle ord har én og kun en betydning i denne kontekst). Her løber vi ind i første hurdle - skal man lave UL på dansk eller engelsk? Der er ikke et entydigt svar, og det ville række for vidt at tage den store diskussion her, så jeg har valgt engelsk. Det kan virke mærkeligt eftersom denne blog er på dansk, men mine læsere bør kunne engelsk til husbehov eftersom de er programmører - og da jeg ikke har en kunde i den anden ende (endnu), er jeg kun en om at skulle være enig om hvad de forskellige termer betyder. Desuden, hvis jeg skulle få den ide på et tidspunkt at oversætte denne artikelrække til engelsk, ville det lette opgaven betydeligt. Som et sidste (og dårligt) argument, kræver min æstetiske sans, at jeg programmerer på engelsk…

Eksempler på UL-termer for et simpelt økonomisystem kunne være:

• Bogholder (Accountant). En typisk bruger af applikationen, som sørger for indtastning.
• KontoPlan/Balance (GeneralLedger). En liste af FinansKonti, som giver et overblik over summen af FinansPosteringer på alle FinansKonti over BogføringsPeriode.
• FinansKonto (LedgerAccount). En gruppering af FinansPosteringer med et fælles formål.
• FinansPosteringer (LedgerEntry). En postering, som viser den beløbsmæssige påvirkning en disposition forårsager. Af revisions- og skattemæssige årsager, er FinansPosteringer ikke redigerbare efter de er dannet.
• FinansKladde (LedgerDraft). En midlertidig samling af FinansKladdeLinjer, som efter at de er gemt bliver til et antal FinansTransaktioner.
• FinansKladdeLinjer (LedgerEntryDraft). En midlertidig representation af en redigerbar FinansPostering.
• FinansTransaktion (FinancialTransaction). En samling af posteringer, som til sammen giver en debet/kredit påvirkning på 0 (det dobbelte bogholderis princip).
• BogføringsPeriode (BookKeepingPeriods). En arbitrær tidsperiode, der typisk strækker sig over et antal måneder.

Som det ses, har jeg gjort en del ud af at gøre sproget så præcist som muligt. Hvis der havde været flere om projektet, ville jeg have uddybet det yderligere og arbejdet meget med at gøre de valgte ord tydelige nok, til at alle var klar over den entydige betydning af termerne. Jeg har samlet mit UL på en statisk side (linket er også vist under “Navigation”), så det er muligt at få et samlet overblik over projektet, som det udvikler sig. Det vil ændre sig efterhånden som projektet skrider frem.

Agil udvikling har en række karakteristika som passer rigtig godt sammen med TDD - egentlig virkede det for mig lidt underligt, at de skulle passe godt sammen, fordi TDD for mig lød som en masse design up-front (BDUF). Jeg har tidligere haft en vis anti-pati mod TDD, fordi jeg bruger meget prototyper - og derfor virkede det som en modsætning at skrive test, før jeg havde fundet ud af hvordan jeg ville lave det. Hvordan kan man skrive tests før man ved, hvordan man ville lave det?

For at starte et sted, startede jeg med Wikipedia’s side om BDD og læste alle links grundigt igennem - og her skete den første åbenbaring: Glem alt om at kalde noget for test - vi laver ikke unit-tests for at teste - vi laver unit-tests for at specificere system-adfærden. Jeg tror den sætning er den vigtigste overhovedet - det var i hvert fald den, der åbnede en prås for mig. Pludselig gav sammenhængen mening - jeg havde siddet og kørt rundt i cirkler med tests af implementationen og ikke adfærden af programmet.

Det viser sig (som flere af grundlæggerne iøvrigt bemærker) at ordvalget kan være kritisk for om man forstår et koncept. Når alt i en test-suite hedder noget med ‘test’, så bliver man fokuseret på test-delen. Man spørger sig selv: “Hvordan kan jeg sikre mig at så meget af min kode bliver testet som overhovedet muligt?”, “Hvornår har jeg nok tests?” osv. En af forfatterne til Wiki-siden prøvede for eksemplets skyld at udskifte alle ord og sætninger, som indeholdet ordet ‘test’ med ‘adfærd’/'burde’ (’behaviour’/’should’) alt efter sammenhængen. Det gjorde udslaget for mig. Det jeg fremover skal koncentrere mig om er, “hvad vil jeg have programmet til at kunne?”, “Hvorkan bør det opføre sig?”.

For øvelsens skyld, satte jeg mig ned med et simpelt problemområde og skrev specifikationerne til, hvordan jeg forventede, at systemet skulle opføre sig (dybest set bare et objekt med en liste af en anden type objekter). Eksemplet har virkelig givet mig blod på tanden - og i de næste par indlæg vil jeg prøve at beskrive processen.