O'Reilly logo

Rails Kochbuch by Rob Orsini

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

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

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required