GrimaceODespair schreef op zondag 01 juni 2008 @ 00:26:
[...]
Volgens mij komt dat gewoon door het feit dat ze niet goed weten wat ze moeten testen. Dan zit je inderdaad maar wat loze testen te schrijven die je om de haverklap moet refactoren omdat je het verkeerde test.
Ik denk dat daar net de bottleneck zit: de feeling hebben om te weten wat je waar moet testen.
Dat is toch irrelevant voor TDD? TDD is juist erop gericht dat je je software designed vanuit de tests die je schrijft. Je gaat niet nadenken wat je moet testen, je gaat je software designen vanuit de tests. Die dan weer user-cases / stories representeren.
Het is juist die aanpak dat je vanuit tests je software gaat designen dat veel mensen niet aanstaat: immers je zit achter je toetsenbord met mocking software je software te designen ipv erover na te denken ZONDER software/editor.
Neem nu ASP.NET. Je kan gaan vloeken over de ontestbaarheid ervan, maar de omgeving en tools voor een project verander je niet zomaar. Dus ben je voor een eenvoudige (!) ASP.NET applicatie mijns inziens eerder een soort integratietesten aan het bouwen dan elementaire unit tests. Je kan wel een extra layer inbouwen, puur voor testability, maar dan ben je 2x werk aan het verzetten, terwijl je doel is: werk besparen.
TDD heeft niet als primair doel werk besparen. TDD is niet geschikt voor ASP.NET (totdat mvc uit komt) omdat je de code voor de pages niet kunt ontwerpen met test + mocks.
Ik vind je voorbeeld overigens niet echt goed gekozen, omdat 'ASP.NET' een UI techniek is en een applicatie veel meer inhoudt dan dat. (UI's kun je bv ook voor een groot deel genereren)
Daar komt nog eens bovenop dat er geen "standaard" werkwijze bestaat voor ASP.NET programming (wie heeft er een sluitende methodiek voor alle page lifecycle en viewstate sores?), waardoor je al test-beginner al snel een ononderhoudbare zooi testen bij mekaar dreigt te schrijven.
Iemand die weet waar z/hij mee bezig is ontloopt de valkuilen, iemand die niet weet waar z/hij mee bezig is, maakt zooi. Dat is niet gerelateerd aan de techniek die gebruikt is, het is een algemene regel.ASP.NET programming is ondoorzichtig soms, maar dat neemt niet weg dat de programmeur zich niet als een amateuristische kleuter dient te gedragen: klanten betalen veel geld voor sites die ze laten maken, de mensen die ze bouwen moeten daarom weten waar ze mee bezig zijn, en daar is geen excuus voor te vinden.
De ASP.NET architectuur leent zich totaal niet voor TDD, tenzij je een MVC framework gebruikt, en wanneer je dat dus niet doet, dan is TDD icm ASP.NET een onmogelijk. Ik snap daarom ook niet zo goed hoe een ASP.NET programmeur TDD zou kunnen gebruiken en dan op zooi uitkomen, het werkt nl. per definitie niet, het stadium zooi bereikt de programmeur niet eens.
En als je dus niemand in de buurt hebt waar je even aan kan vragen: "he, hoe zou jij dit stukje code nou testen?", dan is je enige andere optie: in de theorie duiken. En die zadelt je vervolgens op met een boel kennis die je zelf empirisch moet filteren. En dan haak je af, want daar heb je geen tijd voor.
Of ga ik nou ergens erg kort door de bocht?
Nogal ja. Een programmeur die geen tijd heeft voor het tot zich nemen van kennis die nodig is voor het vak wat de progammeur uitvoert zou m.i. eigenlijk ontslagen moeten worden, tenzij de programmeur 100 uur per week maakt en de werkgever geen seconde leertijd geeft aan de medewerkers.
Dus als de programmeur tegen een probleem aanloopt, dan moet de programmeur daar een oplossing voor zien te vinden, dat is zn vak! En niet een stukje code opzoeken op google, maar even 2 pagina's lezen op een website waarom dit optreed of dat niet werkt etc.
Websites bouwen is echt geen rocketscience, IMHO.
Mijn conclusie is dus: je kan alleen TDD'er worden als je óf bereid bent flink wat onbetaalde uren te investeren, óf in een TDD-omgeving werkt. Hetzelfde kan je uiteraard ook zeggen van ASP.NET, maar ik moet even zoeken naar een reden waarom dat voor mij anders ligt dan TDD. Misschien wel omdat ik het in mijn studententijd heb kunnen oppakken, toen de klok nog 2x zo traag tikte?
Als je met TDD aan de slag wilt, zul je in een project moeten zitten waar de methodiek idd al ingevoerd is, en de technieken waar je ook mee moet werken geschikt zijn voor de TDD werkwijze.
Echter vergeten veel TDDers dat softwareontwikkeling ook op andere manieren kan dan via TDD, dus als het niet toepasbaar is, tja, dan neem je een andere methodiek. Zoals eerst denken en dan doen, verifieren wat je moest maken met wat je gemaakt hebt, algorithmebewijzen etc. Allemaal zaken die al jaren geleden zijn aangedragen voor het bouwen van betere software.
Men heeft er echter gewoon geen zin in: men wil 1 keer iets intikken en dan moet het goed zijn en dan ook nog met zo weinig mogelijk denkwerk vooraf. Je ziet door de jaren heen dat er methodieken worden ontwikkeld om dat te bereiken en die falen allemaal, en dan komt er weer een nieuwe methodiek en daar duikt men dan bovenop, de oude achterlatend. Dat zie je ook bij TDD, waar veel supporters al weer weg zijn en zijn overgestapt naar BDD.
/u/74344/igor_small.png?f=community)
/u/26735/crop5b6e03049ac12.png?f=community)
:strip_icc():strip_exif()/u/1857/crop5a4d06ced6afe_cropped.jpeg?f=community)
/u/14698/odie.png?f=community)
