Die verschiedenen Test Frameworks haben ihre Vor- und Nachteile. Test::Unit ist relativ einfach und schnell. test/spec und RSpec hingegen deutlich lesbarer, jedoch auch langsamer. Sie eigenen sich deshalb besser, um die Tests als Dokumentation zu verwenden. Test::Unit und test/spec verwenden für Viewtests den Umweg über die Controller, was sie im Vergleich zu RSpec deutlich langsamer macht. In Rspec testet man jede Schicht des MVC Musters separat. Das Verhalten der jeweils anderen Schichten wird mit Mocks und Stubs simuliert. Integration Tests mit Cucumber testen dann das Zusammenspiel aller Schichten.

Carlos Dandos und José Valims Remarkable ist das mit Abstand großartigste Plugin für Ruby on Rails, was mir seit langem über den Weg gelaufen ist, denn es reduziert Tests auf das nötigste! Man schreibt in unglaublich expressiver Form, was das erwartete Verhalten ist. Das auf RSpec basierende Remarkable testet mit einer Vielzahl von Custom Matchers die Erwartung ab.

Ein Beispiel für ein Model Validation Test in Test::Unit

class UserTest < Test::Unit
  def test_user_not_valid_if_name_is_blank
    user = User.create
    assert user.invalid?
    assert_equal :blank, :user.errors[:name]
  end
end

Ein Beispiel für ein Model Validation Test in test/spec

context 'User validations' do
  specify 'user should not be valid if name is blank' do
    user = User.create
    user.should.not.be.valid
    user.errors[:name].should == :name
  end
end

Ein Beispiel für ein Model Validation Test in RSpec

describe User do
  it 'should not be valid if name is blank' do
    user = User.create
    user.should_not_be_valid
    user.errors[:name].should == :blank
  end
end

Und jetzt der gleiche Test mit Remarkable:

describe User do
  it { should validate_presence_of(:name) } # RSpec syntax
  should_validate_presence_of :name # Remarkable macro syntax
end

Ok, was musst du tun, um Remarkable verwenden zu können? Falls noch nicht geschen, solltest du das Gem Verzeichnis von Github als Quelle für weitere Gems lokal registrieren:

sudo gem sources -a http://gems.github.com

Danach müssen die benötigten Gems installiert werden:

sudo gem install rspec -v 1.2.6
sudo gem install rspec-rails -v 1.2.6
sudo gem install remarkable_rails

Für alle, die noch eine Rails Version < 2.2 verwenden müssen zusätzlich den I18n Backport von Sven Fuchs installieren:

sudo gem install svenfuchs-i18n

Abschließend müssen im Rootverzeichnis des entsprechenden Rails Projektes noch einige helper scripte generiert werden:

ruby script/generate rspec

Welche Matcher bringt Remarkable mit?

• Matcher für alle Validierungen mit allen Optionen
• Matcher für alle Assoziationen mit fast allen Optionen
• Named Scopes und Massenzuweisungsmatchern
• Datenbank Matcher für Indexes usw.

Ein typischer Unit Test mit Remarkable könnte so aussehen:

require File.expand_path(File.dirname(__FILE__) + '/../spec_helper')

describe User, 'validations' do
  should_validate_presence_of   :username, :email, :password
  should_validate_length_of     :username, :minimum => 6
  should_validate_acceptance_of :agreement
end

describe User, 'associations' do
  should_have_many :images
  should_have_many :posts
  should_have_one  :profile
end

describe User, 'database' do
  should_have_column :activated, :type => :boolean
  should_have_index  :username
end

describe User, 'named scopes' do
  should_have_scope :with_image, :joins => :images
  should_have_scope :activated,  :conditions => { :activated => true }
end

Und von nun an möchte ich nicht mehr hören, dass testen zu schwer sei. Alles Ausreden!

In diesem Sinne, Test frei.

Die Dokumentation für Stripes Unit tests beschreibt sehr ausführlich, wie man mit Hilfe des MockServletContext eine Testinfrastruktur aufbaut, die es ermöglicht die ActionBeans ausserhalb des JEE-Containers zu testen. Dies funktioniert für klassische ActionBeans ganz wunderbar. Doch beim schreiben von Tests für ActionBeans im Wizard Mode fiel auf, dass die Simulation eines Submits nicht funktionierte. Im Wizard Modus erzeugt das Stripes FormTag ein zusätzliches verstecktes Formularfeld mit dem Namen “__fp”, welches alle Feldnamen des aktuellen Formulars in verschlüsselter Form enthält. Ohne dieses Feld verweigert der Stripes Dispatcher die Arbeit! Nimmt man nun einen beliebigen Wert und legt ihn in diesem Feld ab, so erzeugt das ebenfalls einen Fehler:(Der Rechtschreibfehler ist tatsächlich aus dem Framework.)

Stripes attmpted and failed to decrypt the non-null value in the 'fields present' field.

Auch ist es nicht sinnvoll, einen beliebigen Text mit Hilfe des CryptoUtil zu verschlüsseln. Der Submit kann dann zwar erfolgreich simuliert werden, jedoch werden sämtliche Validierungsregel ignoriert. Mit folgenden Zeilen Code, kann ein korrekter Wert für das “__fp” Feld erzeugt werden:

// Alle Feldnamen des aktuellen Formulars in eine Liste aufnehmen
   List fields = new ArrayList();
   fields.add("username");
   fields.add("password");
// Alle Feldnamen mit Trennzeichen zusammenfassen
   String hiddenFieldValue = HtmlUtil.combineValues(fields);
// servlet engine configurieren
   MockServletContext ctx = TestFixture.getServletContext();
   MockRoundtrip trip = new MockRoundtrip(this.ctx, YourCustomActionBean.class);
   HttpServletRequest request = (HttpServletRequest) trip.getRequest();
   hiddenFieldValue = CryptoUtil.encrypt(hiddenFieldValue, request);
   trip.setParameter(StripesConstants.URL_KEY_FIELDS_PRESENT, hiddenFieldValue);

Für das Testen der Feldvalidierung ist es wichtig, dass die Feldnamen mit dem Wert des <input name="" /> Name Attributes in dem jeweiligen Formular übereinstimmen. Denn es werden tatsächlich nur die Felder validiert, die aus dem decodiertem Inhalt des “__fp” Feldes ausgelesen werden können.

Angenommen der oben abgebildete Code wird in der setup() Methode eines Unit Tests ausgeführt und speichert das MockRoundtrip Object in einem privaten Member, könnte ein Beispieltest könnte dann so aussehen:

@Test
public void testLogin() throws Exception {
	trip.setParameter("username", "christophbuente");
	trip.setParameter("password", "secret");
	trip.execute("login");
	YourCustomActionBean bean = trip.getActionBean(YourCustomActionBean.class);
	Assert.assertTrue("Destination", "/account", trip.getDestination());
}

Ich hoffe, dass diese Informationen ausreichen, um sinnvolle Unit Tests für ActionBeans im Wizard Modus zu schreiben. Bei Fragen helfe ich gerne weiter. Und wie immer sind Kommentare sehr willkommen.

“Wer rastet, der rostet.” – So geht es auch Software-Entwicklern. Wer sich nicht ständig nach neuem umschaut und den imaginären Werkzeugkasten mit neuen Tools füllt, wird irgendwann selbst zum alten Eisen gehören. Deswegen habe ich schon vor einiger Zeit angefangen, Ruby on Rails in meine Repertoire aufzunehmen. Diese Woche habe ich in einem 4 Tage Workshop mein Wissen über Ruby und Rails weiter ausbauen können.

[ad#vert-banner]

David A. Black, Autor des Buches “Ruby for Rails” ist für diesen Workshop aus New Jersey, USA angereist. Neben einem ganzen Tag für ActiveRecord und REST, wurden auch Themen wie “routing, testing, caching, deploy, plugins, rjs und javascript behandelt. Das Ganze war gespickt mit hunderten von ad hoc Beispielen, die David in seiner ganz eigenen Art in die Konsole oder den irb hackt.

Derartig tiefgreifende Kenntnis über eine bestimmte Thematik ist mir bisher noch nicht begegnet. Klar, arbeit man hier und da mit Leuten zusammen, die deutlich fitter sind als man selbst. Doch David “lebt” Ruby seit Jahren.

Um hier nicht nur meine Freude für Ruby und Rails zum Ausdruck zu bringen, sondern vielleicht auch ein nützliches Detail zu liefern, möchte ich das Test Framework Selenium erwähnen. Damit ist es möglich über die hoffentlich bereits geschriebenen Unit-, Functional- und Integrationtests hinaus, die Anwendung in einem echten Browser zu testen. Damit kann der Kunde sehr schnell sehen, was geht und was nicht. Und was noch viel wichtiger ist: wie es aussieht in verschiedenen Browsern aussieht.

Die Installation ist schnell und einfach. Im Hauptverzeichnis des Rails Projektes installiert wird das Plugin mit Hilfe des folgenden Kommandozeilen Befehls installiert:

 ruby script/plugin install selenium

Anschließend generiert man eine Testdatei im Ordner test/selenium mit folgendem Befehl:

 ruby script/generate selenium login.rse

Der generierte Testfall muss nun noch editiert werden, um die Applikation sinnvoll zu testen. Dabei können sämtliche Benutzerinteraktionen in lesbarer Form geskriptet werden. Die Kommandoreferenz findet man hier. Sollte die Anwendung bisher noch nicht im Testmodus verwendet worden sein, ist es nötig, die Testdatenbank auf den neuesten Stand zu bringen:

 rake db:migrate RAILS_ENV=test

Damit die Tests auch durchführbar sind, muss der Server im Testmodus gestartet werden:

 ruby script/server -e test

Ruft man jetzt die Rails Anwendung in einem beliebigen Browser auf (http://localhost:3000/selenium) sieht man das Admininterface von Selenium. Hier lässt sich einstellen, welche Tests laufen sollen. Darüber hinaus lassen sich noch die Geschwindigkeit und Highlighting variieren. Ein Klick auf den “Play-Button” im oberen rechten Fenster lässt die Show beginnen. Eine ausführliche Anleitung zur Benutzung des Interface findet man ebenfalls auf der selenium Webseite. Nach belieben können weitere Tests generiert werden und erscheinen dann automatisch im linken Fenster neben dem bereits erstellen login test.

Abschließend möchte ich Benjamin und Mathias danken, dass sie David nach Berlin gebracht haben. Es war spitze!