Zitat:
Bei uns wird nicht mit
Unit-Tests (das ist ja hier im Zusammenhang mit Test gemeint, denk ich) gearbeitet. Nicht weil wir keine Fehler machen, sondern weil... (kann da jetzt kein Agument angeben, dass nicht irgendwer wieder entkräften könnte, aber es läuft auf "Zu Aufwendig für unsere kleinen Projekte" und "So ne neumodische Krams hammer he noch nie jemacht" hinaus).
Deswegen kenn ich mich da nicht aus und frag vllt. dumm. Aber wenn ich statt mit Interfaces mit abstrakten Vorfahren-Klassen arbeite könnte ich doch dagegen testen? Und im Gegensatz zu Interfaces kann es in abstrakten Klassen ja Felder geben und dementsprechend direkt durchgreifende Properties
Und wenn ein Nachfahre mal nicht direkt durchgreift, sondern getter und setter hat, merk ich das von aussen noch nicht mal.
Aber wie gesagt, kenne
Unit-Testing nicht und vermute mal, dass diese Frameworks dafür mit Interfaces arbeiten?
Das mit dem zu "Aufwendig und neumodisch" war bei uns auch anfangs so. Was dieses Thema angeht kann ich Dir/Euch nur Uncle Bob ans Herz legen:
http://cleancoders.com/
Denn Test-Driven Development ist alles andere, als aufwendig ;>
Naja also erst einmal kannst Du das nur, wenn alles was zu testen ist (also alles
) auch vom Basis-Vorfahren implementiert wird. Das bedeutet wiederum, dass Du immer mit dem Typ der Basisklasse arbeiten musst (meineVariable: TBasisklasse) und damit koppelst Du die Verwendung wieder an eine Klasse (dann eben TBasisklasse). Hierfür müsstest Du dann deine Stubklassen für den Test vom Basis-Vorfahren ableiten und musst diese auch immer anpassen, sofern sich etwas (vielleicht irrelevantes für deinen Test) an der Basis-Klasse ändert.
Genau für diesen Fall sind eben nunmal Interfaces gedacht, auch wenn es Sprachen gibt, die dieses abstrakte Modell verfolgen (z.B. Python). Vererbung beschreibt nunmal eine gemeinsame Vorgehensweise und ein Interface eben eine gemeinsame Schnittstelle. Und für den Test unterscheidet sich die Vorgehensweise (die Implementierung) nunmal von der, der Basisklasse