Att designa för testbarhet
Jag har lagt mig till med en ny designtumregel.
Håller på att läsa "Working Effectively with Legacy Code" av Michael Feathers, det är från den följande insikt bubblat upp:
1. Varje klass ska gå att instansiera utan beroenden, varken interna (att den instansierar/anropar metoder i sina metoder) eller externa (beroende på fil / databas etc.).
2. Om en klass behöver externa / interna beroenden, ska dessa skickas med explicit i konstruktorn
Detta gör enhetstestning av klassen möjlig. Och därmed ökar kvalitén på klassen. Och den här stackars kodaren mår bättre :)
Om man måste använda sig av GUI/Databas och annat grejsimojs, kan man försöka bryta ut "logik" ur den koden till "Santas Little Helper"-klasser som man kan testa istället.
Läs även andra bloggares åsikter om tdd, mjukvaruutveckling, testning, programmering
Håller på att läsa "Working Effectively with Legacy Code" av Michael Feathers, det är från den följande insikt bubblat upp:
1. Varje klass ska gå att instansiera utan beroenden, varken interna (att den instansierar/anropar metoder i sina metoder) eller externa (beroende på fil / databas etc.).
2. Om en klass behöver externa / interna beroenden, ska dessa skickas med explicit i konstruktorn
Detta gör enhetstestning av klassen möjlig. Och därmed ökar kvalitén på klassen. Och den här stackars kodaren mår bättre :)
Om man måste använda sig av GUI/Databas och annat grejsimojs, kan man försöka bryta ut "logik" ur den koden till "Santas Little Helper"-klasser som man kan testa istället.
Läs även andra bloggares åsikter om tdd, mjukvaruutveckling, testning, programmering
Kommentarer
Trackback