søndag, maj 25, 2008

Test Driven Development, del 1

Dette er først screencast i en serie om Test Driven Development som jeg har planlagt.

I de kommende indslag har jeg tænk mig at komme ind på:
*Selv arbejdsgangen i TDD.
*Brugen af Mock object for at håndtere eksterne datakilder (sensorer, web services, databaser)
*Hvor TDD hører hjemme i det store billede, herunder brug af BuildServere, versionsstyring mm.

http://www.screencast.com/t/JlyfSqJqKj




For god ordens skyld bør det nævnes at jeg har fået størstedelen af inspirationen og videnen om TDD ved at deltage i fagpakken Programmering af store objekt orienterede system, som er en del af diplomuddannelsen på Århus Universitet. Hermed også en tak til underviseren Henrik Bærbak

4 kommentarer:

Jakob Andersen sagde ...

Godt at se at du prøver at vise TDD til de danske udviklere.

Du siger at du vil lade dine Tests drive dit design, men før du har skrevet en linies testkode laver du dit interface og din klasse.

Det kunne også i dine testcases være interresant at demonstrere RowTest(som vi kender fra MbUnit) som netop er kommet med officielt i NUnit til din 1 og 2 kr's test.

Bedre softwareudvikling og alt andet sagde ...

Det er korrekt at jeg laver mit interface og klasse inden jeg skriver den første testcase. Det er faktisk med fuldt overlæg.

Grunden er, at jeg bestemt ikke er tilhænger af ideen om at smide designfasen ud, men det er et emne som der kan koges meget suppe på :-)
Jeg lader derfor interfacet være givet i forvejen, men jeg beklager at jeg ikke forklarende hvorfor.

Jeg har endnu ikke arbejdet med mdUnit og kender derfor ikke RowTest, men takker ærbødigst for henvisningen.
MbUnit er hermed tilføjet til min TO-DO liste.

Jakob Andersen sagde ...

Okay, det vil være meget interresant hvis du begrunder de valg du laver. Du siger specifikt i starten at dine tests vil drive dit design så der ikke kommer noget overflødigt, hvordan hjælper TDD dig med det når specificerer din funktionalitet på metodeniveau på forhånd, lader du NCover fortælle dig hvad du måske ikke behøver fordi du ikke har testet det?

Hvis man vælger at skrive Test-first er der ingen grund til at skrotte designfasen. Men Test-first er en god måde at finde evt. fejlagtige antagelser du kan have lavet på tegneblokken, så det kan anbefales selvom "man tror" man ved hvordan ens kode ender med at se ud :-) Derudover vil jeg gerne for evt. andre læsere henvise opmærksomheden på "opskriften" fra Test-Driven development by example nu når du selv nævner Beck i screencastet som er fint beskrevet på wikipedia: http://en.wikipedia.org/wiki/Test-driven_development

1. Add a test
2. Run all tests and see the new ones fail
3. Write some code
4. Run the automated tests and see them succeed
5. Refactor code
Repeat

Det er den klassiske fremgangsmåde med TDD og igen er der intet der forhindrer dig i at designe, det forhindrer dig blot i at skrive kode før tests

Bedre softwareudvikling og alt andet sagde ...

Du har fuldstændig ret. Screencastet burde måske nok have heddet: Opsætning af Unit tests 101, for jeg kommer desværre ikke ind på rytmen i TDD, ej heller det sikkerhedsnet som mine unit tests har spændt ud under mig mens jeg refaktoriserer min kode.

I stand corrected.

/K