Rails Kochbuch

First

|

239

Max.

Linie

Max.

Linie

Kapitel 7

KAPITEL 7

Rails-Anwendungen testen

7.0 Einführung

Wenn Sie bei der Vorstellung an Softwaretests erschaudern, dann sollten Sie über die

Alternativen nachdenken und darüber, was Testen wirklich bedeutet. Historisch betrach-

tet, wurde das Testen dem jüngsten Mitglied eines Teams aufs Auge gedrückt, einem

Praktikanten oder jemandem, der nicht wirklich gut war, aber nicht gefeuert werden

konnte (das ist nicht ernst gemeint). Und das Testen fand üblicherweise erst statt, wenn

die Anwendung als »fertig« (oder irgendein Grad von fertig) eingestuft wurde. Oft ist das

Testen ein nachträglicher Gedanke, der die Freigabe genau dann verzögert, wenn man

Verzögerungen am wenigsten gebrauchen kann.

Aber so muss es nicht sein. Die meisten Programmierer empfinden das Debugging als

wesentlich unangenehmer als das Testen. Debugging löst üblicherweise Bilder aus, wie

man auf den Code eines anderen starrt und versucht, dessen Funktionsweise zu verstehen,

nur um den Teil zu korrigieren, der nicht funktioniert. Das Debugging wird allgemein als

unangenehme Aufgabe betrachtet. (Wenn Sie manchmal den Eindruck haben, dass Ihnen

das Debugging einen Kick verschafft, dann stellen Sie sich vor, wie Sie einen Bug beheben,

nur um ihn (vielleicht mit leichten Variationen) gleich wieder auftauchen zu sehen. Der

Spaß am Lösen des Rätsels erinnert da eher an das Aufwischen endloser Flure.)

Die Tatsache, dass das Debugging unangenehm sein kann, ist genau der Grund, der das

Testen interessant und (wie sich herausstellt) auch unterhaltsam macht. Während Sie eine

Testsuite für jeden Teil Ihrer Anwendung aufbauen, ist es so, als würden Sie eine Versi-

cherung abschließen, die das zukünftige Debugging dieses Codes überflüssig macht. Sich

Tests als Versicherung vorzustellen erklärt auch den Test-Begriff »Abdeckung« (coverage).

Code, der Tests für alle erdenklichen Arten der Nutzung besitzt, verfügt über eine exzel-

lente Abdeckung. Selbst wenn Bugs unweigerlich durch Ihre Abdeckung schlüpfen, ver-

hindern die Tests, die Sie zur Behebung dieser Bugs entwickeln, dass diese wieder

auftreten können.

Die Entwicklung von Tests bei der Entdeckung von Bugs ist ein reaktiver Testansatz.

Eigentlich ist das nur Debugging mit eingefügter Test-Entwicklung. Der Ansatz ist gut,

00____RailsKochbuch.book Seite 239 Dienstag, 3. Juli 2007 8:13 08

Max.

Linie

Max.

Linie

240

|

Kapitel 7: Rails-Anwendungen testen

Links

aber es gibt noch einen besseren. Wie wäre es, wenn Sie das Debugging völlig aus dem

Software-Entwicklungsprozess herausnehmen könnten? Die Eliminierung (oder Minimie-

rung) des Debuggings würde die Software-Entwicklung wesentlich angenehmer machen.

Zu wissen, dass Ihr Code solide ist, vereinfacht die Aufstellung von Terminplänen und

minimiert die Möglichkeit unangenehmer Überraschungen, wenn das Freigabedatum naht.

Ein proaktiver Testansatz besteht darin, die Tests zuerst zu entwickeln. Wenn Sie mit der

Entwicklung einer neuen Anwendung oder eines neuen Features beginnen, fangen Sie

damit an, darüber nachzudenken, was der Code tun soll und was nicht. Betrachten Sie das

als Teil der Spezifikationsphase, bei der Sie kein Spezifikationsdokument entwickeln, son-

dern eine Reihe von Tests, die dem gleichen Zweck dienen. Um herauszufinden, was Ihre

Anwendung tun soll, ziehen Sie die Tests zurate. Nutzen Sie sie, um die Entwicklung des

Anwendungscodes zu steuern, und (natürlich) um sicherzustellen, dass der Code richtig

funktioniert. Das wird als testgesteuerte Entwicklung (test driven development, kurz TDD)

bezeichnet: eine erstaunlich produktive Methodik der Software-Entwicklung, die von

Rails hervorragend unterstützt wird.

7.1 Zentralisierung des Anlegens von Objekten

für Testfälle

Problem

Ein Testfall (test case) enthält eine Reihe individueller Tests. Es ist für solche Tests durch-

aus üblich, dass sie gemeinsame Objekte oder Ressourcen nutzen. Statt ein Objekt für jede

Testmethode initialisieren zu müssen, wollen Sie das nur einmal je Testfall tun. Zum Bei-

spiel könnten Sie eine Anwendung besitzen, die Berichtsdaten in Dateien schreibt, und

Ihre Testmethoden müssen jeweils ein Dateiobjekt öffnen, mit dem sie arbeiten.

Lösung

Verwenden Sie die Methoden setup und teardown, um Code in Ihren Testfall aufzuneh-

men, der vor und nach jedem einzelnen Test ausgeführt werden soll. Um eine Datei mit

Schreibrechten in der

ReportTest-Klasse zur Verfügung zu stellen, definieren Sie die fol-

genden

setup- und teardown-Methoden:

test/unit/report_test.rb:

require File.dirname(__FILE__) + '/../test_helper'

class ReportTest < Test::Unit::TestCase

def setup

full_path = "#{RAILS_ROOT}/public/reports/"

@report_file = full_path + 'totals.csv'

FileUtils.mkpath(full_path)

FileUtils.touch(@report_file)

end

00____RailsKochbuch.book Seite 240 Dienstag, 3. Juli 2007 8:13 08