Unit Test vs. Fassaden Tests.. Test der Business Logik

[juniverse]

Ich hätte mal eine grundsätzliche Frage zu Business Tier tests. Ich stehe auf dem Standpunkt, dass man neben Unit Tests innerhalb von Systemen auch fachliche Tests insbesondere auf Schnittstellen, also Insbesondere auf den Fassaden durchführen sollte. Damit meine ich, dass die GP Schicht gekapselt mit einer (oder mehreren) Fassaden(hier dann wohl die Session Beans?!) an genau dieser Stelle mit Realitätsnahen, d.h. Usecase entsprechenden SW Tests penetriert werden sollten. Dabei gehe ich davon aus, dass man pro Usecas mindestens einen Test bauen sollte, der die Anwendung, zum Beispiel durch einen Client simmuliert.
Ich bin der Meinung das irgendwo in der standardliteratur so gelernt zu haben, bzw. ich war bis dato der festen Überzeugung, dass das der Richtige weg ist, die Funktionaltiät zu sichern.
Dagegen ist mein Kollege der Auffassung, dass mit Unit Tests schon genügend Sicherheit herrsche, man Fassaden ("grundsätzlich nicht") teste,("wo hast du das her...") und dass niemand Black box Tests machen soll, weil man damit den Fehler nicht finden würde.
Ich finde Unit tests ja auch vollkommen richtig. Kenn auch eigentlich auch den ganzen xp krams und meine, dass jede SessionBean ja eh getestet werden müsse...
Aber was bitte spricht gegen fachliche Tests auf Fassaden? Ist das nicht das selbe wie Tests auf der Sessiob Beans?
Insbesondere wenn die Usecase komplex sind..
Wie gesagt: meine Vision wäre mindestens ein Usecase pro Feature. Damit will ich Sicherstellen, dass Nebeneffekte nicht neu hinzuprogrammiert werden, die auf dem ersten Blick nicht ersichtlich sind.

Baut man "gewöhnlich" Unit Tests wirklich so sicher (und zwar nicht erst wenn ein fehler auftraucht und man ihn für immer durch einen Unit Test ausmerzen möchte...)
wie mein Kollege sagt? Reden wir an einander vorbei? wieso? Warum ist er so grundsätzlich gegen anständige Usecasebasierte Fassadenpenetration.
Oder macht es keinen Sinn wegen der EJB technologie so zu testen..
(Ich mein, die andere Seite, Mock und so ist mir klar..)
Fragen über Fragen

Wo in der Literatur sagt wer, was? Ich war mir eigentlich trotz verschiedener Ansätze sicher, dass Fassadentests weiterhin zum guten Ton sauber geplanter und gut strukturierter Informationssysteme gehören müssen.. das hab ich doch irgendwo gelesen... domschke holitschke siedersleben, oder sind beck und die xp fraktion wirklich grundsätzlich dagegen??

Ach ja. der Context: global genutztes logistiksystem mit mittelgrößen Datenmengen.
Auf Basis von EJB das gerade neu aufwächst. mit relativ komplexer Business Logik, und trotzdem viel CRUD.

Any geeks arround.?:
thx a lot.

[Ebenius]

In der SQA bin ich nicht so recht bewandert. Trotzdem bin ich mir sicher, dass Unit Tests nicht ausreichen können. Siehe V-Modell. Haste den Kollegen mal mit der englischen Wikipedia erschlagen? Software testing - Wikipedia, the free encyclopedia



Ebenius

[maki]

Kannst dir ja mal das "XUnit Test Pattern" durchlesen, gute info Quelle für Fragen über automatische Tests.

Dein Kollege hat unrecht, neben Unitests, also dem Test von isolierten komponeneten gibt es noch weitere Testarten, die als Integrationstests laufen.
Zu erwähnen wären da zB. das Cactus Framework.
Eine SessionBean kann übrigens eine Facade sein.

Zitat:

	Siehe V-Modell.

Aua, warum denn gleich das Lemmingmodell aufführen wenn Agile Methoden eigentlich besser für Tests geeignet sind

[Ebenius]

Zitat: maki

	Aua, warum denn gleich das Lemmingmodell aufführen wenn Agile Methoden eigentlich besser für Tests geeignet sind

Mir ging's nur darum, dass im V-Modell Integrations-Tests auf Unit-Tests folgen.

Ebenius

[maki]

Nix für ungut, hatte nur schlechte Erfahrungen was das V-Modell und V-Modell XT betrifft

[juniverse]

Danke schonmal soweit. Dass Session Beans die Fassade bilden war mir klar. Die Frage ist nur,
ob es Sinn macht, seine Buisiness Cases Außerhalb aufzusetzen, oder ob es tatsächlich besser organisiert ist das alles und ausschließlich White Box zu machen.
Ich meine dass die Trennung AppServer/ Client gerade danach schreit, von hier Tests sauber gegen die Fassade zu bauen,(zumal es auch mehrere Clients geben soll). Damit kämen die Test dann einer sauberen Komponentenspezifikation des AppS gleich.. Ist das jetzt schon extreme unProgramming , fat und lazy?
Bin ich jetzt altmodisch wenn ich finde, dass sauber definierte Interfaces sich vor allem durch die externe Testcase Erstellung aufsetzen lassen?
Oder sind Unit Test per se einfach sicher? Kriegt man damit sicher Seiteneffekte raus.. Insbesondere bzgl. Datenkonsistenz?... Das X Pattern kuck ich mir mal an.: ) thx.

[maki]

Tests sollten soviel wie möglich gegen eine Blackbox testen, denn damit bleiben sie lose gekoppelt.
Manchmla braucht man eben die Whitebox (zB Mocks), aber da sollte man besonders aufpassen nicht zuviel Wissen über die interna zu prüfen, denn schliesslich können sich interna ändern.

Klar sind SessionBeans gut geeignet um Integrationstests zu schreiben, nur weil die Komponenten im Unittest funzen sagt dass ja noch nichts über das zusammenspiel aus.
IMHO sind aber SessionBeans immer noch zu technisch um rein fachliche Tests zu schreiben, dafür gibt es zB. FIT und Fitnesse.