Test-driven development bij de NLJUG Masters of Java

 
28 november 2008

Bij de Masters of Java-competitie ontwikkel je code op de manier zoals het hoort.

Je begint met het businessprobleem plus een setje testcases. Dan krijg je een halfuur de tijd om code te schrijven, en je moet zorgen dat jouw code al die tests laat slagen. Test-driven design dus. Dat kan bovendien gemakkelijk geautomatiseerd worden, zodat de centrale wedstrijd-server kan controleren of de door jou ingediende oplossing voldoet.

Een goed voorbeeld hiervan was de laatste opgave van dit jaar. De business-case: op een parkeerveld staan een aantal auto’s kris-kras door elkaar geparkeerd. De eigenaar van de Rode Porsche komt naar je toe en hij wil zijn auto NU hebben. De test-cases bestonden uit een aantal parkeerveld-configuraties van verschillende grootte met daarop ook een steeds verschillend aantal auto’s van verschillende lengte die elkaar in de weg stonden.

Nou had je natuurlijk, zoals ondergetekende en zijn programmeerpartner, ijverig in de weer kunnen gaan met een algoritme waarbij je test of de rode porsche een stap naar voren kon; en zo niet, dan keek je of de auto die in de weg stond een naar voren of naar achteren kon. En als dat niet kon dan keek je naar de daaropvolgende auto die verplaatst moest worden. Een mooi recursief probleem dus, waarbij je ook nog eens moest bijhouden of je de auto die je in deze beurt vooruit wil zetten, niet in de vorige beurt net achteruit had gezet.

Maar ondergetekende is niet voor niets op de 9e plaats geëindigd (van de ik geloof 12 of 13, voor het geval je het je afvroeg, ja). De uiteindelijke Echte en Correcte Oplossing van de winnaars van deze ronde was natuurlijk heel anders:

  • tel het aantal auto’s op de parkeerplaats in deze testcase.
  • als er 2 auto’s staan, schuif je eerst de blauwe auto 2 naar voren en kan de Porsche vrij uitrijden
  • als er 3 auto’s staan, doe dan de groene auto 3 naar voren, dan de oranje 2, en dan de Porsche
  • als er 4 auto’s staan, eerst de bruine 2 naar achteren, dan de gele 1 naar voren, de lichtblauwe 3 naar achteren, en dan de Porsche
  • en tenslotte, bij 5 auto’s, eerst de blauwe 2, dan de roze 1, de paarse 2 achteruit, de grijze 1 naar voren, en dan kan de Porsche eruit.
  • Dat waren alle cases. Probleem opgelost.

En toch steekt er iets. Ik weet niet waarom…


Werken met ?
Kijk dan bij onze mogelijkheden voor zowel starters als ervaren engineers.


Categorieën: Development


Reacties (3)

  • Tammo schreef:

    Dit klinkt alsof het hetzelfde ging als vorig jaar.
    Een netjes zoekalgoritme schrijven heb je gewoon geen tijd voor.

    Geplaatst op 28 november 2008 om 12:33 Permalink

  • Ach, als het de testcases voorbijkomt. En niet alleen de winnaar had het, alle 4 de deelnemers die de opdracht binnen het half uur afhadden hebben deze weg gevolgd.

    Sommige mensen begrepen gewoon niet dat het probleem vrijwel niet netjes te doen was binnen 30 minuten..

    Brute-force manier (alle mogelijke zetten doen die je niet terugbrengen tot een patroon dat je al gehad hebt, totdat je een oplossing hebt) is relatief makkelijk te implementeren, maar kost nog redelijk wat code en veel tijd om te testen.

    Subtielere manier (auto’s proberen weg te zetten die in de weg staan, totdat de rode porche eruit kan) zou erg veel code kosten bij ingewikkelde testcases, en er is een vrij grote kans dat je onderweg fouten maakt. Dus ik denk dat we de beste oplossing kozen voor het halen van punten.

    Geplaatst op 28 november 2008 om 11:32 Permalink

  • Ivo Limmen schreef:

    Je hebt gelijk: zo hoort het. Het enige wat ik echter zie in de praktijk is een stukje van de derde zin: “Dan krijg je een halfuur de tijd om code te schrijven, …”.

    Geplaatst op 28 november 2008 om 8:17 Permalink