Hallo allemaal,
Heeft iemand al deze manier van debuggen geprobeerd?
Lijkt me wel een grappige manier van debuggen :-))
Rubber duck debugging
1.245 views
Rubber eendjes horen in het bad ;-)
Ja; eigenlijk wel :-) Als ik echt niet vind wat er misloopt probeer ik perfect te zeggen wat doet deze regel nu, en dan een echo/print_r erbij :-) Daarmee kom je vaak ver.
Nee, met goed TDD heb je al voordat je een method schrijft door wat een method hoort te doen en wat een method doet. Dit hou je tijdens de hele bouw in de gaten, waardoor dit bijna onmogelijk is.
Leuk dat je tegen een rubber eend staat te praten, maar moet dit nou het schaamtegevoel opvangen die je krijgt als je in jezelf zit te praten, waar het feitelijk gewoon weer op neerkomt ;-)?
Wouter J op 30/08/2012 22:45:00
Nee, met goed TDD heb je al voordat je een method schrijft door wat een method hoort te doen en wat een method doet. Dit hou je tijdens de hele bouw in de gaten, waardoor dit bijna onmogelijk is.
TDD?
[size=xsmall]Toevoeging op 30/08/2012 22:49:11:[/size]
- Aar - op 30/08/2012 22:47:10
Leuk dat je tegen een rubber eend staat te praten, maar moet dit nou het schaamtegevoel opvangen die je krijgt als je in jezelf zit te praten, waar het feitelijk gewoon weer op neerkomt ;-)?
Aar, mag ik vragen hoe jij dan debugged? :-)
Mijn manier althans is om iedere lijn te overlopen (of lijnen die bij de fout in de buurt komen) en dan kijken of het wel correct is.
Soms praat ik ook tegen mijzelf als ik dit doe, maar IK ben het maar, niemand zit erbij dus /care
http://acronyms.thefreedictionary.com/TDD
Test Driven Development denk ik.
[size=xsmall]Toevoeging op 30/08/2012 22:52:57:[/size]
Ik heb geen schaamte, ik lul gewoon in mijzelf. In een groep (op kantoor bijv.) dan is het meer gefluister van me. Als er niemand om me heen is denk ik dus hardop.
Je praat dus in jezelf... ;-)
Test Driven Development denk ik.
[size=xsmall]Toevoeging op 30/08/2012 22:52:57:[/size]
- Raoul - op 30/08/2012 22:47:22
Aar, mag ik vragen hoe jij dan debugged? :-)
Mijn manier althans is om iedere lijn te overlopen (of lijnen die bij de fout in de buurt komen) en dan kijken of het wel correct is.
Soms praat ik ook tegen mijzelf als ik dit doe, maar IK ben het maar, niemand zit erbij dus /care
Ik heb geen schaamte, ik lul gewoon in mijzelf. In een groep (op kantoor bijv.) dan is het meer gefluister van me. Als er niemand om me heen is denk ik dus hardop.
Je praat dus in jezelf... ;-)
Hardop denken doe ik dan weer minder, maar goed iedereen zijn eigen manier hé :-)
Hoe ik debug op errors: Ik kijk eerst naar de error, deze geeft al zoveel informatie. Vervolgens kan ik bijna altijd al gericht gaan zoeken in de code. Ik ga dan eerst die regel af en dan ga ik regel voor regel, ergens binnen 5 regels bereik van de errorregel kijken of ik iets vreemds kan vinden. Nog steeds niks? Dan locate ik de error, ik comment elke regel totdat de error verdwenen is. Die regel isoleer ik dan weer om te zien of er nog steeds een error is en dan heb ik de error vaak wel gevonden, met eventueel wat Googlen erbij.
En TDD is Test Driven Development. Je schrijft eerst een test waarin je opschrijft wat je verwacht dat er gaat gebeuren:
<?php
class CalculatorTest extends \PHPUnit_Framework_TestCase
{
public function testSum()
{
$calculator = new Calculator();
$this->assertEquals(12, $calculator->sum(10, 2));
}
}
?>
Deze test faalt natuurlijk, dan maak je die specifieke functie en voer je de test weer uit, dan wordt het een succes. Dan ga je hem wat moeilijker maken, door bijv. $this->assertEquals(12, $calculator->sum(3, 6, 3)); te doen.
Hierdoor weet je precies welke functie voor wat dient en je hebt geen functie die onnodig is, je script immers alleen waarvoor je tests schrijft.
Dit principe hoeft natuurlijk niet alleen op OO/klassen toegepast te worden, maar ook op functies of gewone variabelen.
En TDD is Test Driven Development. Je schrijft eerst een test waarin je opschrijft wat je verwacht dat er gaat gebeuren:
<?php
class CalculatorTest extends \PHPUnit_Framework_TestCase
{
public function testSum()
{
$calculator = new Calculator();
$this->assertEquals(12, $calculator->sum(10, 2));
}
}
?>
Deze test faalt natuurlijk, dan maak je die specifieke functie en voer je de test weer uit, dan wordt het een succes. Dan ga je hem wat moeilijker maken, door bijv. $this->assertEquals(12, $calculator->sum(3, 6, 3)); te doen.
Hierdoor weet je precies welke functie voor wat dient en je hebt geen functie die onnodig is, je script immers alleen waarvoor je tests schrijft.
Dit principe hoeft natuurlijk niet alleen op OO/klassen toegepast te worden, maar ook op functies of gewone variabelen.
Wouter, als het effectief gaat om een error, dan is het inderdaad niet extreem moeilijk om deze op te lossen. Ik hanteer dezelfde methode als jou.
TDD binnen PHP heb ik nog nooit gedaan, in Java wel (met JUnit). Alleen, vind ik die tests soms wel erg arbeidsintensief. Want je moet in principe alle cases uitproberen.
TDD binnen PHP heb ik nog nooit gedaan, in Java wel (met JUnit). Alleen, vind ik die tests soms wel erg arbeidsintensief. Want je moet in principe alle cases uitproberen.
Ik sla het bestand op, open het op de server en kijk of hij doet wat ie moet doen.
Bij errors deze uiteraard eerst oplossen (reden staat in de error).
Geeft hij onverwachte errors (of doet het wat anders dan ik dacht), dan gewoon stukje voor stukje controleren op de logica.
Zo was ik gisteren ergens een $i++; vergeten.... en maar raar vinden dat er 1 resultaat getoond werd, terwijl een print_r($result); wel gewoon alle resultaten gaf...
Bij errors deze uiteraard eerst oplossen (reden staat in de error).
Geeft hij onverwachte errors (of doet het wat anders dan ik dacht), dan gewoon stukje voor stukje controleren op de logica.
Zo was ik gisteren ergens een $i++; vergeten.... en maar raar vinden dat er 1 resultaat getoond werd, terwijl een print_r($result); wel gewoon alle resultaten gaf...