lilith2k3 Geschrieben 6. September 2010 Geschrieben 6. September 2010 (bearbeitet) Hallo, ich habe mal wieder ein Brett vorm Kopf Es geht sich um folgendes: Ich habe eine X-beliebige Klasse, die ich Testen will. In diese Klasse möchte ich ein Dummy-Objekt einfügen, was "nix" macht. Also gesagt getan. Ich bilde eine Dummyklasse: class Dummy : Original { new public void Originalmethode { } new public void AndereOriginalmethode } naja usw. So, daß ich jede Originalmethode mit new überdecke und anstelle dessen meine Dummy-Methode aufrufe - So der Plan! Und nun kommt mein Problem. Ich muß ja irgendwie meinen Dummy in das testobjekt einbauen. Da ich weiß, daß mein Dummy per Polymorphie reinpasst, übergebe ich ihn anstelle des Originalobjektes. Allerdings hab ich irgendwo noch einen Denkfehler: Denn anstelle der Dummy-Methoden werden natürlich schön brav die Originalmethoden aufgerufen. Irgendwo hab ich was übersehen, ich weiß aber noch nicht was? Jemand eine Idee? Danke :] P.S.: Was natürlich klappt, ist die Originalmethoden virtual deklarieren und dann das ganze per override überschreiben. Aber das ist nicht das Verhalten, welches ich will *hrmpf!* Bearbeitet 6. September 2010 von lilith2k3 Zitieren
lbm1305 Geschrieben 6. September 2010 Geschrieben 6. September 2010 Zum Testen würde ich ein Mock-Framework nutzen. Da muss man in der Regel keine Dummyklassen erstellen. Zitieren
lilith2k3 Geschrieben 6. September 2010 Autor Geschrieben 6. September 2010 Zum Testen würde ich ein Mock-Framework nutzen. Da muss man in der Regel keine Dummyklassen erstellen. Äh, ja, im Prinzip ist es ja das, worauf ich hinaus will *g* Nur, daß das Framework ja auch irgendwie arbeiten muss. Und wenn ich den Kniff heraushabe wie, wäre ich ein Stück weiter. Btw. inwieweit taugt NMock denn was? Zitieren
lbm1305 Geschrieben 6. September 2010 Geschrieben 6. September 2010 Ich persönlich bevorzuge RhinoMocks. Außer dem SUT (System Under Test) wird normalerweise alle gemockt. Von Vorteil wäre hier ein Interface. Zitieren
Ze29 Geschrieben 6. September 2010 Geschrieben 6. September 2010 Als Mocking Framework würde ich nicht NMock nehmen sondern ein moderneres Framework das mit Lamdas arbeitet. Anbieten würden sich da z.B. Moq oder Rhino Mocks. NSubstitute sieht ebenfalls sehr gut aus. Die Mocking Frameworks arbeiten unter der Haube mit dynamischen Proxy Klassen. Was ganz anderes als dein Ansatz. Zitieren
lilith2k3 Geschrieben 6. September 2010 Autor Geschrieben 6. September 2010 Okay. Ich geb's auf Ich hab meinen Fehler gefunden ... *g* In der abgeleiteten Klasse kann eine virtuelle Methode auch mit dem Modifizierer new ausgeblendet werden. Dann verdeckt die geerbte Methode in der Subklasse die Implementierung der Basisklasse und zeigt kein polymorphes Verhalten mehr. Moq hab ich mir auf die Schnelle auch mal angesehen... das scheint nicht übel zu sein. Zitieren
NerdonRails Geschrieben 7. September 2010 Geschrieben 7. September 2010 Ich persönlich bevorzuge RhinoMocks. Außer dem SUT (System Under Test) wird normalerweise alle gemockt. Von Vorteil wäre hier ein Interface. Guter Mann. RhinoMocks ist wirklich ziemlich gut, besonders wenn es um das testen State-behafteter Klassen geht oder um Klassen die einfach nur mies zum Testen sind bzw. wo das drüberliegende Framework einfach testunfreundlich designed wurde (z.B. LinqToSql oder EntityFramework, wobei das EF dank POCO und Mocking-Framework doch testbar ist). Wenns nichts großes ist kann man auch mit dem Strategie-Pattern und DependencyInjection arbeiten und kann sich das Mocking-Framework sparen Zitieren
Empfohlene Beiträge
Dein Kommentar
Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.