Ich bin in den vergangen Tagen über mehrere Blogeinträge gestolpert, die sich mit dem Thema Farben in Unit Tests (also , bei deren Ausführung) beschäftigt haben. RedGreen ist etwas unelegant, da man statt einfach rake einzutippen rake | redgreen schreiben muss.

Mit diesem kleinen Patch und dem colored Gem geht dann doch alles vollautomatisch. Toll.

Update: gerade ist mir aufgefallen, dass die Tests, wenn man sie innerhalb von TextMate ausführt, recht unansehnlich werden, da TextMate die entsprechenden Codes plain ausgibt, statt die Schrift farbig werden zu lassen. Bisher hatte ich oben genannten Patch in eine Datei colorized_tests.rb gepackt und diese mittels require File.expand_path(File.dirname(__FILE__) + '/colorized_tests')am Ende von test_helper.rb eingebunden. Um die Farbcodes in TextMate abzustellen, habe ich noch ein unless ENV["TM_PROJECT_DIRECTORY"] dahintergehangen. Jetzt sehen die in TextMate ausgeführten Tests wieder wie gewohnt aus, und bei rake gibt’s trotzdem Farben. Cool.

Da unsere vielen Tests mittlerweile ein wenig lange brauchen, haben wir uns am heutigen Forschungstag mal wieder mit dem Problem Testing auseinandergesetzt. Das Ergebniss diesmal schon vorne weg: unsere erfolgreichste Entdeckung ist Mocha.
Mit diesem Framework lassen sich Stubs und Mocks mit realen Objekten verwenden. Es folgt ein kleiner Auszug aus unserem bisherigen Testcode.

Dauer: 795ms

Nach kurzem Studium des Mocha Cheat Sheets haben wir dann den Test wie folgt geändert.

Dauer: 49ms

Na wenn das keine signifikate Verbesserung ist. Auf Mocha gestoßen sind wir über den Testing Rails Blog, auf dem leider nichts Neues mehr zu passieren scheint. Eine kleine Übersicht von Stub-Frameworks mit problemspezifischen Einschätzungen fanden wir auf dem Blog von Jay Fields.

Wir werden Mocha in der nächsten Zeit in unseren Test integrieren, und bei der 2000ten Revision sagen wir euch wie lange unsere Test Suite läuft.

Wir haben wieder einen Grund zu Feiern. Die 1000ste Revision. Hier mal ein paar Zahlen über dieses Jubiläum. Man beachte die Code to Test Rate

+----------------------+-------+-------+---------+---------+-----+-------+
| Name                 | Lines |   LOC | Classes | Methods | M/C | LOC/M |
+----------------------+-------+-------+---------+---------+-----+-------+
| Controllers          |  1588 |  1336 |      30 |     175 |   5 |     5 |
| Helpers              |  1335 |  1146 |       3 |      97 |  32 |     9 |
| Models               |  2566 |  2068 |      40 |     258 |   6 |     6 |
| Libraries            |  1693 |  1416 |      10 |      61 |   6 |    21 |
| Components           |     0 |     0 |       0 |       0 |   0 |     0 |
| Integration tests    |   179 |   157 |       2 |      16 |   8 |     7 |
| Functional tests     |  3496 |  3034 |      61 |     389 |   6 |     5 |
| Unit tests           |  8551 |  6355 |      43 |     448 |  10 |    12 |
+----------------------+-------+-------+---------+---------+-----+-------+
| Total                | 19408 | 15512 |     189 |    1444 |   7 |     8 |
+----------------------+-------+-------+---------+---------+-----+-------+
Code LOC: 5966     Test LOC: 9546     Code to Test Ratio: 1:1.6

Auf vielfachen Wunsch kann man ab sofort bei kommt-mit das Reisedatum auch bis zu 3 Jahre in der Vergangenheit angeben - endlich können also auch die schönsten Reisen von früher mit korrektem Datum versehen werden.

ganz schoen nerdig, aber naja, trotzdem nett. hier isser:

Audio clip: Adobe Flash Player (version 9 or above) is required to play this audio clip. Download the latest version here. You also need to have JavaScript enabled in your browser.

(via CoderPath)

Endlich ist es so weit - nach nunmehr 3 Monaten Entwicklungszeit geht kommt-mit.de online. KommtMit ist die erste deutsche web 2.0-kompatible Community für Reisen und Ausflüge.

Plant vom nächsten Strandurlaub über die Fahrradtour, die Klassenfahrt, den Traumurlaub irgendwann mal, die Dienstreise, das Gruppenseminar bis hin zur Weltumrundung alle eure Reisen.

Auf KommMit könnt ihr:

• alle Freunde einfach zu euren Reisen einladen
• mit der Aufgabenliste im Voraus klären, wer denn nun den Dosenöffner nicht vergessen darf oder wer für’s Picknick zuständig ist
• auf der Pinnwand den Abfahrtstermin diskutieren
• im Kochbuch Rezepte heraussuchen und euch eine Einkaufsliste zusammenstellen lassen
• ein Reisetagebuch führen: für die zu-Hause-Gebliebenen und die Erinnerung
• Fotos hochladen (und sogar angucken )
• das Reiseziel anhand von Satellitenbildern und Fotos erkunden

.. und noch so einiges mehr. Wir freuen uns über jeden Besucher und auch über Feedback, denn noch ist die Seite im Betatest. Neuigkeiten ab sofort dann immer hier im Blog.

in the last days i started implementing caching for autoki.com. my first stop was this excellent rails caching tutorial over at railsenvy.com.

basically, rails offers 3 ways of caching page content:

• page caching: an entire page gets stored on the hard disk and can then be served by apache instead of rails - very fast but almost useless for us, as every page has some dynamic element in this. we still consider it for some ajax calls.
• action caching: also caches the entire page, but it’s still served by rails, which means before_filters for stuff like authnetication still work - still not for us, see above
• fragment caching: as the name implies caches fragments of a page - yay, sounds good

fragment caching

the basics are really easy. first, you simply surround the parts of the page that you want to cache with a <% cache ' … <% end %>. this writes the fragment to a file in /tmp/caches and from now on, rails serves this part of the page from the cache.

this alone doesn’t get you any performance improvements yet, because your controller is still loading all the data from the database before rendering the view. to avoid this, you wrap your data loading code into unless read_fragment 'name' ... end blocks - now you page should be running lightning fast already.

the third problem to tackle is to clean the cache at the right time. this can either be done in the controllers by calling expire_fragment 'name' or by using so called sweepers. they are basically observe your models and clean the right fragments on events like after_create - so when you add a new user to the system, you can clean the list of users from the cache.
(more…)

Da wir uns diese Woche etwas um die Laufzeit unsere Tests gekümmert haben, war das Thema unseres letzten Forschungstages “besser testen in Ruby on Rails”. Da Testen bereits Thema bei Peepcode war, war der Screencast Pflicht. Der brachte leider kaum neues. Doch ganz zum Schluss wurden dann doch noch zwei praktische Tools vorgestellt. Mit TestTimer (gem install test_timer) läst sich die Laufzeit aller einzelnen Test messen. So lassen sich echte Langläufer ausmachen. Ein weiteres sehr praktisches Tool ist FakeWeb. Damit lässt sich Http-Kommunikation simulieren - perfekt, um die Testumgebung von externen Seiten zu entkoppeln ohne den Produktionscode zu ändern. Hier mal ein Beispiel aus der Dokumentation.

def test_request
FakeWeb.register_uri(’http://example.com/test_me’, :string => “Hello World!”)
content = Net::HTTP.get(URI.parse(’http://example.com/test_me’))
assert_equal “Hello World!”, content
end

Bei unserer Rechereche im Netz stießen wir zu guter Letzt noch auf einen kleiner Helfer, der automatisch jede Seite auf gültiges HTML prüft, jedem Link folgt, jeden Ajax Link aufruft und Formulare mit zufälligemn Daten füttert. So lassen sich Routing-Fehler, fehlende Seiten und falsche Formulare leichter aufspüren. Dieses Plugin hat den passenden Namen SpiderTest. Auch hier ist die Verwendung kinderleicht.

def test_spider
get ‘/’
assert_response :success

spider(@response.body, ‘/’)
end

SpiderTest befindet sich noch in der Entwicklung.

So das waren unsere Ergebnisse mal kurz zusammengefasst. Über hilfreichreiche Tipps und Kritik freuen wir uns, genauso wie über jeden netten Kommentar

schnell anmelden, unter https://ssl-id1.de/re-publica.de/akkreditierung/

FileColumn ist ein wirkliches zauberhaftes Plugin fuer Ruby on Rails. All unsere Bilder-Uploads haben wir bisher damit umgesetzt. FileColumn bietet Helper, um Datei-Uploads zu bauen und kann die hochgeladenen Bilder natuerlich auch wieder anzeigen. Das eigentlich schoene ist aber die Integration mit RMagick, einem Ruby-Binding fuer ImageMagick, wodurch sich Bilder on the fly skalieren sowie beschneiden lassen und die verschiedenen Versionen dann automatisch im Dateisystem landen. Alles, was man dazu braucht, ist eine Zeile Code im Model, z.B.

Dieser Code erzeugt neben der Originalversion 3 Kopien: Eine 238 Pixel breite und entsprechend des Bildformats hohe, eine gestauchte, genau 23 x 35 Pixel grosse und eine genau 73 x 73 Pixel grosse, beschnittene Version.

So weit alles schoen. Das einzige Problem war, dass unsere Unit-Tests durch FileColumn ganz schoen langsam wurden. Bei jedem Testdurchlauf, der irgendwas mit Bilder zu tun hatte, wurden jedes mal mehrere skalierte Versionen erzeugt, was natuerlich Rechenzeit kostete. Die Loesung haben wir letzte Woche dann endlich mal zusammengehackt, und sie sieht so aus: Ein Modul, was von FileColumn installierte Callbacks ausser Gefecht setzt, wird in ein Mock des Models eingebunden, aber der Reihe nach. Hier das Modul, gelegen in test/file_column_mock.rb:

In unserem Beispiel wollen wir die Klasse User von ihrer FIleColumn-Last befreien. Dazu legen wir in test/mocks/test eine Datei user.rb an und fuellen sie mit folgendem Inhalt:

Der Effekt des ganzen ist, dass die Original User-Klasse aus app/models nochmals geoeffnet und mehrere Methoden, die normalerweise automatisch beim Setzen des photo-Attributs loslaufen, umd die skalierten Versionen zu erzeugen, durch Ueberschreiben ausser Gefecht gesetzt werden.

Das war’s. Und schon fliegen die Tests wieder mit voller Geschwindigkeit.