Path: csiph.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: "Christian H. Kuhn" Newsgroups: de.comp.lang.java Subject: =?UTF-8?Q?Re:_Unit-Tests_von_Einheiten_ohne_=c3=b6ffentliche_Lesesc?= =?UTF-8?Q?hnittstelle?= Date: Fri, 8 Jul 2016 14:13:15 +0200 Lines: 28 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: individual.net o1M5u6DCsrtCYJBz6wAYFgmIwH5dRLRs3HvbEmKYtmtfyhVVI= Cancel-Lock: sha1:isdOE7DEGxx2ypn2jRKgeuyx6V8= User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 In-Reply-To: Xref: csiph.com de.comp.lang.java:12977 Am 08.07.2016 um 00:28 schrieb Patrick Roemer: > Genau dieser Ansatz sollte eigentlich in jedem TDD-Buch abgehandelt > werden. Die Nomenklatur ist allerdings herzlich inkonsistent: Das läuft > unter "Mock", "Shunt", "Stub", "Fake",... Ah. Bei mir ist Mocking in der anderen Richtung angekommen: Wenn ich in meinem Beispiel die Schachuhr vor den Einzeluhren entwickelt hätte, hätte ich für die Uhren Mocking-Objekte benutzt, die auf definierte Aktionen definierte Ergebnisse liefern. Solange, bis ich dann eine getestete Klasse für die echte Uhr habe. Die Transferleistung, dass das Mocking-Objekt auch auf höherer Stufe in der Klassenhierarchie als die zu testende Klasse ansiedeln kann, war dann zu schwer für mich. > Ich kann kaum glauben, dass eine Websuche mit "swing junit" nichts > zutage fördert... > > [1] Kent Beck, "Test-Driven Development by Example" > [2] Gerard Meszaros, "xUnit Test Patterns" > [3] http://www.jgoodies.com/download/presentations/patterns-and-binding.pdf Ich melde mich wieder, wenn ich fertig mit Lesen bin :-) Vielen Dank! mfg QNo