Agil, Scrum - R*vknulla programmerare?

Tack för tipset! Blir nog ett köp där.


Den TDD jag har erfarenhet av fokuserar just på testningen i sig som ett sätt att driva utvecklingen (som namnet antyder), inte att kvalitetssäkra produkten. Hur är det i ditt fall? Använder ni TDD bara som ett sätt att göra "test-after" före och garantera att allt är testat, eller är det en mer central del i hur koden ser ut?

Som jag upplever det så förloras själva meningen med TDD om man modellerar sitt system på förhand.

Blogg som tar upp skillnaden mellan TDD och TAD som representerar den syn på systemutveckling som jag inte känner mig attraherad av:
http://stephenwalther.com/blog/archi...velopment.aspx
Kommentarerna är speciellt intressanta.

Jag skulle säga att TDD i själva "skapandeprocessen", inte är någonting som kommer påverka din arkitektur nämnvärt, men kommer antagligen höja kvaliten på din kod. För att enkelt kunna testa och skapa snygga testklasser, så kommer jag bli tvungen att bryta ut allt till små, enkla metoder som bara gör en sak.

Med 100 snyggt namngivna test, kopplad till min slutgiltiga kod, så kommer det innebära att alla som någonsin kommer gå in i min kod och ändra någonting, aldrig kommer kunna förstöra någon av den funktionalitet jag skapat utan att det börjar "smälla" i en massa tester. Så klåpare kommer inte kunna checka in kod som skapar buggar i den funktionalitet jag byggt upp.

Jag ser inte att du argumenterar så mycket för TDD utan mer testning i allmänhet. Vad är det i TDD, den version som du står för, som inte inte kan uppnås med "test after" eller rent av "test after before"?

Och enhetstestning i sig kan nog vara ett bra incitament för att skriva enkla metoder som bara löser en specifik sak, men det klarar man nog utmärkt ändå med lite utbildning och/eller sunt förnuft.

TDD fungerar enligt min erfarenhet sämre ju större projektet är och ju tajtare schema man har. Fokusen för TDD ligger alltför mycket på enhetstesterna, medan de svårfixade buggarna sträcker sig över flera komponenter (d.v.s. är i någon mening integrationsbuggar).

För att maximera effektiviteten i sådana projekt så tycker jag att man ska prioritera:

• Välskrivna designspecifikationer med tydligt spikade API:n (design by contract).
• Defensiv programmering.
• Dedikerat folk som enbart skriver och underhåller komponent- och ände-till-ände tester.

Men det är bara min egen åsikt.

Vinsten man får av TAD är aningen robustare kod, till priset av längre utvecklingstid. TAD tenderar att testa implementationen av kod och inte kodens "kontrakt", vilket gör koden jobbigare att refaktorisera. Genomkasst alltså.
TDD tar längre tid stt koda än att inte testa alls, det tar dock kortare tid än TAD eftersom testerna snabbar upp utvecklingen av produktionskoden. Resultatet blir mer robust kod, testad på korrekt sätt (förenklar förståelse och refaktorisering). Den lilla extratid som krävs för TDD är försvarbar.

Varför skulle TAD testa koden på ett annat sätt än TDD? Man ser väl till att metoderna gör det de ska, misslyckas man med det är man väl bara en kass testare?

Vad är det som gör att TDD snabbar upp utvecklingen?

För egen del så är jag speciellt förtjust i modelleringen av systemet jag utvecklar, förutom att jag tycker att det mycket roligare och utvecklande att arbeta med aritekturen än att implementera, så har jag märkt att ju större del av systemet som jag modellerar, desto enklare och snabbare går det att implementera allt och få det att fungera.

Och detta är ju inte alls kompatibelt med TDD, där man uttryckligen inte skall modellera systemet på förhand, utan där man iterativt ska hitta på och uppfylla lite tester som man tror representerar en funktionell del i systemet som man behöver. Då kan man ju tänka sig att systemet blir ett arkitektuellt lapptäcke.

Vi kan väl vara överens om att modelleringsdriven utveckling inte är kompatibel med testdriven utveckling? Eller är bloggen jag länkade till ovanför helt fel ute?