Posts Tagged lambda

Ik las recentelijk in een blog-entry van Rob Conery over BDD. Rob Conery ontwikkelt voor Microsoft een op ASP.NET gebaseerde StoreFront. Een soort starters-pakket voor mensen die een web-winkel willen maken. In het proces van het ontwikkelen van deze applicatie (die inmiddels ook op Codeplex is geopensourced onder de werktitel Kona heeft hij meerdere ontwikkel-processen en ontwikkel-methodes uitgeprobeerd. En in dat hele proces was hij er niet vies van om de hele zaak op zijn kop te gooien of zelfs helemaal opnieuw te beginnen. Alleen daarom al is hij een held. O, ja, en ook omdat ie op Hawaii woont…

Zo kwamen de afgelopen maanden Test-Driven-Development, Domain-Driven-Development en -als meest recente- Behaviour Driven Development langs. BDD is min of meer uitgevonden door Dan North (http://dannorth.net/introducing-bdd) en lost voor mij (en ook voor Rob Conery) een probleem op dat ik altijd met TDD heb gehad: hoe begin je met je tests?

Natuurlijk ga je eerst je test maken en dan pas de code die zorgt voor het vervullen van je test. We kennen het allemaal: red-green-refactor. Maar met welke test begin je, en hoe heet die test?

BDD doet iets heel simpels: denk niet meer in de term “test” maar in termen als “gedrag” en “specificaties”. Dus: “welk gedrag wil ik implementeren” en niet “welke test wil ik schrijven”. Je komt dan heel makkelijk op iets als “EmptyShoppingCartShouldReturnCountOfOneWhenProductAdded”. Dat kan ik vertalen naar een test en ik kan ook de code schrijven die de test vervult!

De volgende stap is dat je al de requirements/specs/behaviours die je kent op een dergelijke manier in je code zet. Gewoon lege methods met aan Assert.Fail erin. Dat geeft je een hele lijst van test-methodes die natuurlijk initieel allemaal falen. Maar het is dan wel zonneklaar wat je moet gaan doen om de hele zaak groen te krijgen.

Dit lijkt niet revolutionair, maar ik heb het vandaag in de praktijk uitgeprobeerd en het leverde me een zeer tevreden gevoel op. Ten eerste wist ik wat ik moest gaan coderen, ten tweede wist ik dat ik een test had voor alle code die ik zou gaan maken en ten derde wist ik -eenmaal aan het einde van de rit, alles groen- dat ik niet meer code had gemaakt dan ik nodig had.

Ik zou ook dolgraag de volgende stap maken: het inzetten van MSpec (). Albert Oudenampsen had mij al eens RSpec laten zien: in feite een Ruby-programmaatje dat het mogelijk maakte om je specificaties in bijna-menselijke-taal te schrijven en te executeren. Maar zoals wel vaker duurt het bij mij enige maanden tot jaren voordat ik zie wat Albert ziet. MSpec is op de ideeen van RSpec gebaseerd, maar is specifiek voor het .NET platform.

MSpec biedt een library die je meelinkt in je test-project en die je de taal-elementen geeft waarmee je je tests (sorry, je behaviours) schrijft en biedt je een MSpec-runner die de behaviours runt en over de resultaten rapporteert. Je neemt dus je requirements-document, schrijft in MSpec-syntax je tests en runt het hele zaakje met de MSpec-runner. Vervolgens ga je zorgen dat de specs/behaviours groen worden door net als bij TDD te gaan implementeren. Even een stukje code om er een gevoel bij te krijgen:

   1. [Description]
   2. public class Transferring_between_from_account_and_to_account
   3. {
   4.   static Account fromAccount;
   5.   static Account toAccount;
   6.
   7.   Context before_each =()=>
   8.   {
   9.     fromAccount = new Account {Balance = 1m};
  10.     toAccount = new Account {Balance = 1m};
  11.   };
  12.
  13.   When the_transfer_is_made =()=>
  14.   {
  15.     fromAccount.Transfer(1m, toAccount);
  16.   };
  17.
  18.   It should_debit_the_from_account_by_the_amount_transferred =()=>
  19.   {
  20.     fromAccount.Balance.ShouldEqual(0m);
  21.   };
  22.
  23.   It should_credit_the_to_account_by_the_amount_transferred =()=>
  24.   {
  25.     toAccount.Balance.ShouldEqual(2m);
  26.   };
  27. }

Naast het feit dat de specificatie redelijk te lezen is (als je even gewend ben aan de syntax die nogal zwaar leunt op ambda-expressies) produceert de MSpec-runner ook een HTML rapport waarop staat welke requirements je allemaal gaat implementeren, welke er al klaar zijn en welke nog niet. En dat allemaal op een manier die leesbaar is voor project-managers of problem-owners.

Nog niet overtuigd? Laat ik het dan anders zeggen: je hebt executeerbare requirements! Ja, echt, daar wordt je blij van, dat geeft je de missing-link tussen dat ene Word document dat die FO-er heeft geschreven en jouw eigenste code!