Fremde Typen mockt man nicht?

[thecain]

Mich hat diese Aussage von @mrBrown gerade ein bisschen zum Nachdenken gebracht, aber wollte nicht den Thread verwüsten, in dem es stand.

außer den EntityManager, aber fremde Typen mockt man nicht

Ich hab bisher den EntityManager immer fröhlich gemockt. Meist so ähnlich: https://www.adam-bien.com/roller/abien/entry/mocking_jpa_entitymanager_with_query

Das hatte den Vorteil, dass ich keine H2 Datenbank starten musste und die Tests sehr schnell ausführbar waren. War ich hier immer daneben oder ist das mehr eine persönliche Präferenz?

 

[mrBrown]

Von Mockito selbst: Don't mock a type you don't own.

Ich hab bisher den EntityManager immer fröhlich gemockt. Meist so ähnlich: https://www.adam-bien.com/roller/abien/entry/mocking_jpa_entitymanager_with_query

Das hatte den Vorteil, dass ich keine H2 Datenbank starten musste und die Tests sehr schnell ausführbar waren. War ich hier immer daneben oder ist das mehr eine persönliche Präferenz?

Entkoppelt Business-Code und Datenbank-spezifischen Code, zb mit Repository oder DAO-Pattern

Um mal bei dem Beispiel von Adam Bien zu bleiben: Der Test läuft auch erfolgreich durch, wenn die Query vollkommener Unsinn ist, zB einfach ein leerer String oder der EntityManager völlig falsch benutzt wird. Das muss also in jedem Fall zusätzlich gegen eine echte Datenbank getestet werden, ansonsten testen man den Großteil des Verhaltens gar nicht.

Einfach lösen kann man das, wenn man dann einfach Business-Logik und Datenbankzugriffe entkoppelt, zB indem man ein RegistrationsRepository einführt. Dieses kann man dann zum Testen der Business-Logik testen und zusätzlich selbst gegen eine echte Datenbank testen.

 

[thecain]

Das muss also in jedem Fall zusätzlich gegen eine echte Datenbank getestet werden, ansonsten testen man den Großteil des Verhaltens gar nicht.

Ja, klar. Das wäre dann bei "mir" der Integration Test, der in einem TestContainer läuft.

Deine Argumentation ist auch stimmig für mich soweit. Ist wahrscheinlich auch ein bisschen ein Paradigma. Wir halten uns zum Beispiel Architekturtechnisch stark an Adam Bien, keine Ahnung warum, ist scho seit Jahren so. Er vertritt auch sehr stark die Meinung keine Layer einzubauen nur um der Abstraktion willen. Heisst, wenn der Service oder das Repository nur ein durchreichen auf den Entitymanager ist, kann auch direkt der EntityManager verwendet werden. Wenn man später den Layer braucht kann er immer noch hinzugefügt werden.

Meine ursprüngliche Frage hat sich aber geklärt und ich verstehe die Argumentation dahinter.

 

[mrBrown]

Er vertritt auch sehr stark die Meinung keine Layer einzubauen nur um der Abstraktion willen.

Wenn man das konsequent durchzieht programmiert man in Maschinensprache, alles andere ist doch nur Abstraktion um der Abstraktion Willen

Heisst, wenn der Service oder das Repository nur ein durchreichen auf den Entitymanager ist, kann auch direkt der EntityManager verwendet werden. Wenn man später den Layer braucht kann er immer noch hinzugefügt werden.

Ich würde sinnvolle Kapselung nicht nur als "Abstraktion um der Abstraktion Willen" bezeichnen, grad in Bezug auf Übersichtlichkeit und Testbarkeit gewinnt man einiges dazu, was dann auch bei nötigen Umbauten hilft.
Wenn man ein extra Repository einführt verliert man nichts, gewinnt aber saubere Trennung zwischen den einzelnen Teilen und macht das Testen sich noch eine ganze Ecke einfacher.

Grad das von dir genannte Beispiel ist sogar nur ein Durchreichen des Entitymanagers, wenn man das Prinzip ganz durchzieht müsste man auf die dort "getestete" Klasse verzichten und das direkt in die Resourcen-Klasse ziehen.


Ich finde Adam Bien durchaus in vielen Teilen gut, aber grad dieses Beispiel (mag dem Alter geschuldet sein) ist relativ schlecht und eher eine Sammlung von Antipatterns als ein gutes Beispiel 😅