aanpassen

Het testen van een testloze Rails applicatie

Geplaatst door Matthijs Langenberg do, 26 apr 2007 14:55:00 GMT

Veel applicaties zijn niet vanaf het begin geschreven met goede tests (of helemaal zonder tests). Hoe ga je te werk wanneer je je Rails omgeving gaat upgraden, of wanneer je grote aanpassingen gaat maken in je code?

In een ideale wereld zou je alleen je test suite alleen te hoeven uitvoeren: De reden dat ik altijd zo hamer op het schrijven van testen, het liefst door middel van een test-first aanpak als Test Driven Development of Behaviour Driven Development. Helaas is deze ideale wereld vaak een utopie.

Enkele weken geleden heb ik me bij Newminds bezig gehouden met het migreren van een applicatie (die niet met een test-first aanpak is geschrijven) naar Rails-1.2. Nadat ik de vendor/rails map een update naar 1.2 had gegeven werkte de mogelijkheid om documenten te downloaden niet meer. Nu had ik op dat moment direct uit kunnen zoeken wat het probleem vormde en had ik de bug uit de applicatie kunnen halen (wat ik ook gedaan heb), maar bij het tegenkomen van meerdere bugs in de applicatie ben ik tot de volgende werkwijze gekomen om structureel fouten op te sporen in een applicatie welke nog geen testen bevat.

Stap 1: Loop handmatig door de applicatie tegen totdat er iets niet meer naar behoren werkt.

Ik kreeg een Rails error op het moment dat ik naar ”/documents/download/handleiding.pdf” ging.

Stap 2: Schrijf een test die deze fout blootstelt. (niet meteen de fout oplossen!)

Wanneer ik “documents/download/handleiding.pdf” aanroep verwacht ik dat de “download” actie van de “DocumentsController” wordt aangeroepen met als ‘id’ parameter “handleiding.pdf”. Dus schrijf ik de volgende integratie test:

class DownloadroutesTest < ActionController::IntegrationTest
    def test_download_route
        assert_routing 'documents/download/handleiding.pdf',
            :controller => 'documents', :action => 'download', :id => 'handleiding.pdf'
    end
end

Vanaf nu is het heel duidelijk dit een fout in je applicatie is: wanneer je rake test start zal deze test falen. Nu mag je ervoor kiezen om deze fout op te lossen of om verder te gaan zoeken naar nieuwe fouten. Het beste is om door te gaan met zoeken naar nieuwe fouten, je zult merken dat het veel sneller is om door een applicatie heen te lopen en voor elke tegengekomen fout een test te schrijven dan on the fly fouten gaan opsporen en oplossen.

Als het goed is heb je nu een aantal testen die de fouten in je applicatie blootstellen. Deze lijst van testen zijn prima te gebruiken als taakverdeling voor een aantal werknemers en geven ook een goed idee van de hoeveelheid fouten in je applicatie, kortom goed bruikbaar voor een planning.

Stap 3: Los nu een voor een de gevonden fouten op, je geschreven testen helpen als een gids om erachter te komen wat je nu precies verwacht en of je exact aan deze verwachting voldoet.

Aangezien binnen Rails-1.2 ’;’ en ’.’ als scheidingstekens binnen de routering worden gezien: ‘handleiding.pdf’ wordt naar { :id => 'handleiding', :format => 'pdf' } omgezet. Moet ik de volgende regel aan routes.rb toevoegen:

 map.connect 'documents/download/:id', :requirements => { :id => /.*/}, :controller => 'documents', :action => 'download'

Nu slaagt mijn zojuist aangemaakte test wat betekend dat de fout verholpen is. Voor de zekerheid kun je nogmaals naar de eerste stap gaan.

Op deze manier los je structureel fouten op in je applicatie, ga je het vinden van fouten lostrekken van het oplossen van fouten en begin je langzaam maar zeker met het schrijven van een test suite voor je testloze applicatie.

“Bezint eer gij begint.”