On 29-09-12 19:44, Remco Gerlich wrote:
Hoi,
En hoe kom je er achter wat stuk blijkt te zijn zonder het te testen?
Hoe kom je erachter of je overal tests voor hebt geschreven?
___
Python-nl mailing list
[email protected]
http://mail.python.org/mai
On Sep 30, 2012, at 12:57, Marcel van den Elst wrote:
> On 29-09-12 19:44, Remco Gerlich wrote:
>> Hoi,
>>
>> En hoe kom je er achter wat stuk blijkt te zijn zonder het te testen?
> Hoe kom je erachter of je overal tests voor hebt geschreven?
Dat klinkt als een retorische vraag, maar zo niet:
Hi,
Aanleiding was de vraag of test *driven* development de juiste weg is.
Als je echt test-driven ontwikkelt schrijf je eerst tests, dan schrijf
je code tot je tests passen. Als je dan code coverage doet zul je
waarschijnlijk concluderen dat je code gecovered is.
Maar het voorbeeld van de R
Op Sun, 30 Sep 2012 13:28:24 +0200 schreef Marcel van den Elst
:
[...]
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 n
On Sat, 29 Sep 2012 18:45:09 +0200
Marcel van den Elst wrote:
> De link tussen knuffelen door bedrijven en vrijdagavond en testcases
> snap ik niet, maar ik sluit me van harte aan bij de gedachtengang
> over tests:
Het doet me plezier dat je tenminste een deel van mijn redenering hebt
kunnen vo
Dank voor jullie reacties! Genuanceerd bloggen blijkt lastiger dan
gedacht... Anton's reactie geeft al beter weer wat ik bedoelde, maar
wellicht is dit blog niet de juiste plaats dit soort spinsels te spuien.
Vooropgesteld: `untested code is broken by design` (Django). En je
krijgt los van de
