- checking out Ernest's work on VAStGoodies: http://tinyurl.com/bhhhdh #
|
||||||
In de podcast waar o.a. Kent Beck niet zo blij mee was, heeft Joel Spolsky een voorbeeld van een stukje code waar het meer moeite kost om een test eerst te schrijven, dan dat het wat oplevert. Het gaat over het aanpassen van de jpeg compressie in een stukje remote control software via een toolbar button. Wat hij als test ziet is de actie uitvoeren en het resultaat terug krijgen van een remote machine en dan controleren of twee images gelijk zijn. Veel werk om te automatiseren, maar in mijn vocabulaire heet dit dan ook een integratie test. Hij zegt zelf dat het enige dat hij hoeft te coderen is dat de button een een bepaalde waarde als parameter mee gaat geven. Ik neem aan dat het geen extra if statement is in een procedure van 100 regels die alles doet, dus begrijp ik niet wat er zo moeilijk aan is om dit te unit testen. Een test hiervoor heb ik ook in om en bij vijf regels code geschreven, afhankelijk van taal en test framework. En als er toch zo een high coupling is tussen de modules wat het moeilijk maakt, dan is het juist TDD dat ervoor zorgt je de code wat beter modulair opzet. Dat je een betere scheiding krijgt tussen gui en backend. Een andere keer had hij het namelijk ook over een incident waar het veranderen van de menustructuur allerlei testen kapot maakten. Ja dat zijn automatische testen, maar ik durf te wedden dat ze achteraf geschreven zijn. En in dat geval dus niks met het TDD concept te maken. Anyway, je moet altijd kritisch lezen en luisteren, maar als het gaat om meningen van Joel over zaken die uit de Agile hoek komen, ben ik altijd extra alert.
Een kenmerk van agile werken is de feedback loop. Door incrementeel steeds iets werkends opleveren, heb je een moment om te evalueren en bij te sturen. De dagelijkse standup meeting zorgt voor een feedback loop per dag en zo kun je steeds fijner gaan. De feedback loop gaat in Smalltalk door tot het allerlaagste nivo. Als je de applicatie aanpast door code te wijzigen dan zijn deze meteen beschikbaar voor de draaiende applicatie. De applicatie waaran je werkt gaat dus niet down. Je wijzigt het gedrag van bestaande levende objecten en je kunt de veranderingen meteen observeren. Een voorbeeld is een invulformulier op het web dat uit meerdere pagina's bestaat. Je hebt de eerste pagina gemaakt en gaat het testen. Je vult de pagina in en klikt op 'verder', maar omdat er nog geen tweede pagina is krijg je een debugger. Op dat moment begin je gewoon met het eerste invulveld op je tweede pagina en als die klaar is kun je gewoon 'verder' gaan van de plek waar je gestopt bent met dezelfde sessie en dezelfde instanties van objecten. Klopt het veldje, dan ga je weer verder met de volgende. Maar werk je dan niet maar een enkele pad uit in de applicatie? Klopt, maar je kunt ook je levende object instanties een bepaalde state geven om in een ander pad van de applicatie te komen. De instantie vraag je op en pas je aan met een scriptje in je workspace:
Deze scriptjes kun je bewaren om steeds in een bekende staat terecht te komen. En zo ga je dus incrementeel verder totdat je aan het eind van de dag een compleet ingevuld formulier kunt submitten. In talen als java, kan de IDE je wel helpen om automatisch te builden en te deployen als je code hebt aangepast, maar je state raak je steeds weer kwijt dus maak je grotere stappen in een keer om tijd te besparen. Het duurt dan echter wat langer voordat je weet of je goed zit. Hoe krachtig het concept is wordt geillustreerd in een quote over een moment die de computer industrie heeft verandert, het bezoek van Steve Jobs aan Xerox en de demo van Smalltalk:One of the best parts of the demo was when Steve Jobs said he didn't like the blt-stye scrolling we were using and asked if we cold do it in a smooth continuous style. In less than a minute Dan found the methods involved, made the (relatively major) changes and scrolling was now continuous! This shocked the visitors, espeicially the programmers among them, as they had never seen a really powerful incremental system before. The rest is history.
|
||||||
|
Copyright © 2010 soemirno - All Rights Reserved |
||||||