P
hustbaer schrieb:
@pumuckl:
A auf B zu templatisieren wäre keine Lösung (A<B> für produktiv und A<BMock> zum Testen)?
Nein, damit wäre gegenüber void A::SetB(B*) nichts gewonnen. Im Gegenteil, ich müsste im A-Header noch die komplette Implementierung stehen haben, weils ja jetzt ein Template ist. Das würde die Kapselung des Ganzen noch mehr aufbröseln.
brotbernd schrieb:
Aufrufe zählen, -> Mock
vorher angegebene Werte zurückliefern, -> Stub
Sind natürlich nur Namen und diese werden bestimmt auch unterschiedlich angewendet. Aber ich glaube i.A. werden Mocks und Stubs danach unterschieden, an welchem Objekt dir Verifizierung stattfindet. Bei Mocks wird die Übeprüfung am Mock selber vorgenommen, beim Stub am Testobjekt.
Dann ists ein Mock. Am Mock-Objekt werden sowohl die Aufrufe gezählt, als auch die Rückgaben für die erwarteten Aufrufe eingestellt. Je nach Framework wird dann das mock-Objekt bei zu vielen/zu wenigen Aufrufen eine Exception werfen oder bei einer späteren Abfrage einen Fehlerwert zurückliefern.
Zu deinem Problem fällt mir jetzt grad auch keine weitere grandiose Lösung ein ausser dass A seine BFactory über irgendeinen weiteren globalen Service (Singleton?) bezieht, der sich umkonfigurieren lässt. Es ist irgendwo ein Kompromiss zwischen Kapselung und Erweiterbarkeit.
Danke, das klingt gut. Ich hatte sowieso vor, für jede Schicht eine Fassadenklasse zu definieren (es sind aktuell genau 7 Schichten/Module und werden kaum mehr werden), und abgesehen von der obersten Schicht gehören alle nicht zur API des Frameworks. Ich könnte also eine allgemeine Fassaden-Factory definieren, die ebenfalls nicht zur API gehört, der ich aber sagen kann "gib beim nächsten GetXYFacade-Aufruf dieses Mock-Objekt statt der echten Fassade zurück" Das wäre dann eine einzige interne Klasse, deren Interface ich für Testzwecke anpasse. Damit könnte ich leben
Nachtrag: zusätzlich hätte die Fassadenfactory die Möglichkeit, einzelne Fassaden nach dem Decorator-Pattern mit Loggern auszustatten, abhängig von einer Konfigurationsdatei.