Op Sun, 30 Sep 2012 13:28:24 +0200 schreef Marcel van den Elst
<i...@marutec.nl>:
[...]
Maar wat als je het probleem nog niet goed begrijpt en door aan de slag
te gaan probeert te achterhalen waavan je een vage notie hebt? Dan is
test *driven* wellicht niet de logische keuze.
Ik zou dat persoonlijk niet beschouwen als een serieuze poging om code te
schrijven om een probleem op te lossen.
Dat begint m.i. pas als je het probleem helder hebt en dan kun je gewoon
de cyclus "test schrijven" - "te testen code aanvullen" in.
"Crash-driven" klinkt voor mij meer naar wat ik een manager laatst hoorde
roepen: "jullie moeten crash-vrije programmatuur opleveren" oftewel goed
werkende maar volstrekt nutteloze programmatuur is ook goed (ik snap wel
dat dat niet bedoeld wordt, maar hoe makkelijk is het om jezelf voor de
gek te houden?).
Het goede van testdriven development (en design!) is dat je van te voren
stilstaat bij hoe je bepaalt of iets goed is, in plaats van dat je dat
achteraf probeert te reconstrueren. Als het goed is ben je daar toch al
een beetje mee bezig, dus waarom dat niet gelijk vastleggen?
--
Gemaakt met Opera's revolutionaire e-mailprogramma:
http://www.opera.com/mail/
_______________________________________________
Python-nl mailing list
Python-nl@python.org
http://mail.python.org/mailman/listinfo/python-nl
