Tittar på att gå ett steg längre med TDD-workshops och lämna de grundläggande ämnena. Följande har efterfrågats:
- testning med/av legacy code
- vad är bra respektive dåliga test
- funktionell eller acceptansdriven testning (ATDD)
- beteende driven utveckling (BDD)
Egna saker jag själv skulle vilja gräva lite mer i och ägna ett par timmar åt:
- hamcrest (matchers)
- dotmesh (methods)
- making EasyMock suck less
- making Mockito suck
- easyB
- Fitnesse
I allmänhet så saknar jag en diskussion om hur lättredigerade test (wiki?) versionshanteras ihop med koden de testar eller är skrivna mot. Detta är ju högst intressant när man går in och gör en hot-fix för en produkt som rört sig mycket under ett år, och en kund som har produkten i drift sedan ett drygt år tillbaka vill sin fix. Hur kör man samma testsvit som man hade för ett år sedan på ett enkelt sätt? Hur är egentligen inte svårt. Jag har bara inte sett många bra lösningar, ännu. TextTest, xUseCase och liknande plain text-ramverk är en bra lösning. Frågan är bara om testen är tillräckligt tillgängliga för ATDD – hur får man kunden att känna att det är hans/hennes test?
Hej Fredrik!
Ett forum för att diskutera mer verklighetsnära TDD och hjälpa varandra att hitta praktiska lösningar vore intressant. Detta har jag ju nämnt på Meetup; http://www.meetup.com/JDojo-Gbg/events/16296997/
De gånger jag var med vet jag att det efterfrågades hur man testar privata metoder. Vet inte om det besvarades de gånger jag missade, men – om vi bortser från det “ideologiska” i huruvida man testar dem – så är det annars en detalj man skulle kunna ta upp.
Något jag själv fått kämpa förvånansvärt mycket med att få till en heterogen testsvit, där man blandar Spring-preparerade tester med mockade tester, utan att saker som auto wire och JTA-transaktioner sätts ur spel. Lite det som behandlades på senaste JavaForum i ett EJB-perspektiv.
Något jag inte haft tid att titta konkret på, som jag gärna skulle vilja få tips om, är hur man bäst mockar tester av filer – både läsning och skrivning. En stor del av vårt system består i att parsa filer till dataobjekt, och skriva data från objekt till filer i en mängd olika format (XML, flatfiler etc). För att komplicera det hela är viss data t.ex. tidsstämplar, så i utgående filer räcker det inte att jämföra med en statisk mall, utan det måste gå att sätta upp regler för undantag (t.ex. XPath att exkludera) eller på annat sätta göra en dynamisk assert.
En annan intressant fråga är vad man bäst testar med Selenium och vad man testar med JUnit? Skall man köra Selenium mot en lättviktsinstans av applikationen där allt under GUI-lagret är mockat…?
En mer abstrakt diskussion skulle handla om att hur man redan på arkitektur- och designstadiet förbereder för god testbarhet. Det innebär ett stort hinder att införa TDD när man målat in sig i ett hörn där det är svårt eller omständigt att göra enhetstester. Ofta kan detta undvikas genom att man tänker till från början.
P.S. Om du vill bli bättre på Hamcrest matchers så rekommenderar jag LambdaJ. Även om Mockito använder matchers var det först när jag började med LambdaJ som jag kände att jag började greppa dem.