Gute objektorientiert entworfene Systeme zeichnen sich dadurch aus, dass es eine hohe Interaktion mit anderen Objekten gibt. Idealerweise zerlegt eine Klasse ein Problem nur bis zu dem Punkt, an dem es sich einer anderen Klasse bedienen kann, die dieses einfachere Problem l\u00f6st. Schwierig wird es, wenn eine eigene Klasse auf eine andere komplexe Klasse zur\u00fcckgreift und das Objekt nur dann sinnvoll arbeitet, wenn das referenzierte Objekt da ist und irgendwie sinnvoll antwortet. Diese Abh\u00e4ngigkeit ist ung\u00fcnstig, denn das Ziel eines guten Tests besteht ja darin, lokal zu sein, also die eigentliche Klasse zu testen und nicht alle referenzierten Klassen um sie herum gleich mit.<\/p>\n
In der Praxis begegnen uns drei Hilfskonstrukte, die die Lokalit\u00e4t von Tests erm\u00f6glichen:<\/p>\n
Diese drei Typen k\u00f6nnen wir unter dem Oberbegriff Dummy-Objekt\u00a0zusammenfassen. Grunds\u00e4tzlich gilt bei den vier Begriffen aber, dass sie von Autoren nicht einheitlich verwendet werden.[1]<\/a><\/p>\n Beispiel: Mockito-Beispiel<\/p>\n Nehmen wir an, alles aus org.mockito.Mockito.* ist statisch importiert und wir wollen eine java.util.List aufbauen. Dazu muss Mockito erst etwas aufbauen, was sich wie List verh\u00e4lt:<\/p>\n List<?> mockedList = mock( List.class );<\/p>\n Im n\u00e4chsten Schritt muss das Verhalten der speziellen Liste bestimmt werden:<\/p>\n when( mockedList.get(0) ).thenReturn( „tutego“ );<\/p>\n Anschlie\u00dfend ist die Liste bereit zur Nutzung:<\/p>\n System.out.println( mockedList.get(0) ); \/\/ tutego<\/p>\n