Det eneste som kommer fra baseklassen ConsoleTestingFixture i testen min over er propertien Output. Det er liten tvil om hva den representerer, og å skjule hvordan jeg faker bort System.Console er en god ting.

I tillegg har jeg ennå tilgode å treffe folk fra “den andre siden” som er interessert i slike rapporter som MSpec genererer.

Da velger jeg heller å skrive BDD-inspirerte tester, men formatet mitt avviker fra Torbjørn sitt: Jeg foretrekker at alt som synes i test-metoden også skal deklareres i samme test-klasse. Hvis ikke, så opplever jeg det som at her finnes det en del magiske variable man bare er nødt til å vite er der.

Ikke så problematisk for lesbarheten, men mer når man senere skal legge til flere tester.

Og ja, rapportene som MSpec lager kan absolutt være en grunn til å gå for det rammeverket. Men når det gjelder hva som er realistisk så tror jeg strengt tatt det er mye enklere å få utviklere til å lese gode enhetstester i visual studio enn å få dem til å lese en liste med spesifikasjoner. I alle fall når det skal inn å gjøre en endring, og trenger å forstå hvordan en klasse, eller et sett med klasser som utgjør en adferd, fungerer.

Dog, en av de store fordelene med MSpec er output’en etter at testene er ferdige, og det vil jo du mangle hvis du ikke implementerer noe selv. Det er dem andre i bedriften evt. vil lese, for la oss vaere realistiske og ikke tro at andre enn programmerere vil lese kode nesten uansett hvor leselig den blir. Og selv din kode er mindre leselig enn MSpec’s output. Kanskje du kan klare det ogsaa?

Ellers vil jeg bare nevne at jeg var saa heldig at jeg var paa samme fantastisk gode opplegg med Scott Bellware og at det er lite tvil om at man blir inspirert av saa dyktige folk som ham. :)