Danke, für Deinen Input.
So wie ich Dich verstehe, werden bei diesem Ansatz wohl oder übel
eine ganze Reihe BO-Code in JavaScript implementiert werden.
Dies wollte ich eigentlich überhaupt nicht, denn
- Wie modelliere ich am besten tests? Firewatir wäre eine
Möglichkeit ist aber sehr langsam.
- Ändere ich das DB-Schema, so muss ich den JavaScript-Code ggf.
ändern. Dies widerspricht der ActiveRecord Philosophie, dass alles
durch das DB-Layout definiert wird.
Nimmt man beide Punkte zusammen, so gibt dies imho eine teuflische
Mischung:
Wo knallt der JavaScript-Code, wenn ich ein Feld im DB-Schema
umbenenne?
hmm, so rosig ist die Welt ja aber auch in rails ja nicht, oder?! Wenn
man in den Views explizit Felder referenziert, die dann aus der
Datenbank verschwinden oder dort umbenannt werden, dann knallt es da
auch im view - das ändert sich auch mit JavaScript als View nicht -
dein View ist also macht die DB-Felder also so oder so explizit und
ist daher auch von Änderungen abhängig. Es sei denn, man kommt
wirklich mit einer scaffolding-Lösung aus, die das ganze über
Introspektion löst. Das scheint aber in den seltensten Fällen wirklich
richtig gut bis in alle Verästelungen einer größeren Anwendung hinein
zu funktionieren, oder hat da jemand andere Erfahrungen?! Schlimmer
wird's dann ja noch, wenn man irgendeine Art von Geschäftslogik auf
diesen Feldern abstützt (z.B. Konto nur belasten, wenn Konstostand >
0), dann lässt sich das DB-Schema erst recht nicht mehr ändern, ohne
dass es knallt - insgesamt kann ich den Satz, dass __nur__ das DB-
Layout die Anwendung definiert, so - zumindest für uns - nicht
bestätigen.
Wo knallts's bei uns: In der Regel an den selben Stellen, wo es auch
in normalen Views knallt: Wenn ein Feld dazu kommt, dann wird es nicht
automatisch angezeigt, da muss man in einer Tabelle das entsprechende
Feld dazu tun, den Editoren beibringen was sie wie anzuzeigen haben
usw. - die Schichten dazwischen sind davon nicht betroffen:
dem .to_json ist es natürlich egal, was es serialisiert...- knallen
tut's daher an denselben Stellen, an denen es auch bei der Verwendung
von vielen partials und rjs knallt: Nämlich jedesmal, wenn man etwas
rendert was nicht mehr da ist oder umbenamst wurde usw.
selenium und firewatir benutzen wir nicht: das ist mir alles zu
fragil, zu kompliziert aufzusetzen und man ist eigentlich die meiste
Zeit damit beschäftigt, diese Testframeworks zum Laufen zu bringen,
aber vielleicht fehlt mir da einfach die Geduld (hat das jemand in
aller Schönheit mit Continous Integration und allem am Laufen??!)...
Wir testen komplett getrennt, erst den Server, dann die Clients.
Beinah jedes js-framework hat eigentlich ganz vernünftige unit-tests
(z.B. GWT, http://www.ibm.com/developerworks/java/library/j-cq07247/index.html
oder sproutcore, http://wiki.github.com/sproutit/sproutcore/unit-testing
oder auch die div. unit-test-frameworks für prototype oder jquery -
muss man zwar alles von Hand machen (gwt testen geht allerdings auch
von Eclipse aus) und es läuft nicht in der Continous Integration mit,
aber es ist viel praktikabler: Reicht in der Regel auch eigentlich
aus, weil die beiden Schichten klarer getrennt sind: Man kann ja den
Client auch erstmal ohne Server nur mit Mocks entwickeln.... - sooo
teuflisch find ich das also eigentlich gar nicht: Man muss da nicht
religiös werden, wenn's ans Testen geht: Es geht ja nicht um eine
besonders beeindruckende Toolkette, sondern nur darum, Fehler zu
finden und rauszuholen, egal wie....
Viele Grüße
Stefan
_______________________________________________
rubyonrails-ug mailing list
[email protected]
http://mailman.headflash.com/listinfo/rubyonrails-ug
