Finns det någon här som yrkesmässigt anser sig ha tillämpat äkta testdriven utveckling, och i så fall vill du kanske dela med dig av dina erarenheter ?

När jag skriver "äkta" så menar jag att man alltid skriver testkoden innan man faktiskt implementerar metoderna som skall testas.
Det räcker alltså inte att man i efterhand har skapat lite JUnit/NUnit tester för att det ska räknas som äkta TDD.

Själv kan jag inte riktigt säga att jag har tillämpat äkta TDD, men jag har "nästan/delvis" gjort det i två projekt.

Det ena var ett litet java projekt (en liten och väl avgränsad del av en f.ö. stor applikation) som var mycket väl lämpat för att skriva testkod (metoder med input-strängar och output-strängar).
Då använde jag Eclipse, vilket underlättade rejält för att skriva testerna först då man bara skriver ett namn på en icke-existerande klass/interface, och sedan med enkla tangenttryck på CTRL+1 så kan man enkelt generera den nya typen. På samma sätt genererar man enkelt skeletten för metoderna som skall testas.
Här använde jag egentligen äkta TDD, men projektet var så pass litet (med endast ca 20 typer) så därför tycker jag inte riktigt att det kan räknas som att ha äkta erfarenhet av TDD vilket man kan få i ett stort projekt.

Mitt andra "nästan-TDD-projekt" utvecklade jag med C# i Visual Studio.NET 2005.
Det här var en lite större applikation men jag testade inte all kod på riktig "unit test" nivå, och inte heller alltid renlärigt "test-first" utan parallellt med implementeringen så valde jag ut de klasser/metoder som kändes mest väsentliga att skriva testkod för.
Jag fokuserade mest på att testa CRUD-resultatet av metoderna i den högsta nivån Application Layer, eller GRASP Controller, eller vad man nu vill kalla det första lagret (efter GUI-lagret) med metoder på use case nivå. Jag testade här att metoderna hämtade eller tryckte in rätt saker (och t.ex. inte dubbla inserts) i databasen m.h.a. NDbUnit (som man använder genom att i en XML-fil definiera databasens innehåll före respektive efter anropet på den metod som testas) samt testade att de uppdaterande metoderna inte modifierade något i databasen vid felaktig input. Dessutom automatiserade jag testerna för den logik som definierar huruvida olika knappar i webbapplikationen ska vara visible/enabled eller inte, vilket styrdes av olika tillstånd/parametrar som kunde kombineras på totalt flera hundra sätt. Så många testfall vill man verkligen inte testa igenom manuellt, så här kändes testkoden mycket meningsfull !

I båda projekten kände jag att jag hade nytta av testsviterna, bl.a. för att jag ibland upptäckte oönskade sidoeffekter som behövde åtgärdas när ny kod lades till eller att problem upptäcktes vid en refaktorisering.
Dessutom är jag övertygad om att dom som numera förvaltar respektive projekt har nytta av testerna.
Det som jag kanske uppskattade allra mest var känslan av att faktiskt våga refaktorisera sin design vid förändrad kravbild, och slippa känslan av att "det är säkrare att göra ett enkelt fulhack än att göra en snyggare lösning men därmed också riskera nya buggar" som är en ofrånkomlig känsla i en stor applikation då man inte har en testsvit av tillfreddställande storlek.

Nästa gång jag får chansen att jobba med nyutveckling skulle jag verkligen vilja jobba med renlärig TDD.
Vilka erfarenheter har ni av renlärig TDD ?
Har ni t.ex. kanske varit skeptiska innan men blivit mer positiva efter att själva ha testat i verkliga projekt ?

Testdriven utveckling... Är inte det när man försöker fixa en bugg genom att göra en ändring i koden på måfå och testa om det hjälpte? ;-)