RhinoMocks - Holen der Parameter der aufgerufenen Funktionen

Mit RhinoMocks - kann ich Holen die Parameter einer aufgerufenen Funktion? Ich meine; kann ich einige der unbekannten Parameter aus dem Aufruf der Funktion aus?

Habe ich ein mock -, und ich erwarte, dass einige Funktion, die aufgerufen werden auf diese. Ich weiß, dass einer der Parameter, der andere aber unbekannt ist, wie die von der Klasse verwendet, die spotten und ruft eine Funktion auf. Mehr spezifisch - in diesem Fall - das unbekannte argument ist eine lambda-Funktion. Dies ist eine callback-Funktion soll aufgerufen werden, wenn die Funktion beendet. Als die mock-verhindert, dass der callback nicht aufgerufen wird möchte ich, um es zu Holen, und Sie rufen mich.

So, ich will, um zu überprüfen, dass die Funktion aufgerufen wurde. Ich möchte sicherstellen, dass einige der Argumente wurden erwartet. Und ich möchte, um aus der unbekannten Argumenten zu tun, einige Operationen auf Sie Sie anschließend.

Vorausgesetzt, beide Argumente Ganzzahlen (der Einfachheit halber) ich würde gerne etwas wie das hier tun: 

int unknownInt; 
_fakeSomething.AssertWasCalled(factory => factory.Foo(1, out unknownInt));
//then play around with unknownInt..

Kann das getan werden? Ich sehe, es ist ein Arg.Aus, konnte aber nicht ganz, damit es funktioniert..

Hinweis: Aktualisiert die Frage, wie es zu sein schien irreführend.

InformationsquelleAutor stiank81 | 2010-01-13
  1. 15
    Arg<string>.Matches(arg => you got the argument here...);

    UPDATE:

    Zu Holen, das zweite argument auf den ersten Anruf der Foo Methode auf _fakeSomething:

    string someArg = null;
var args = _fakeSomething.GetArgumentsForCallsMadeOn(
    x => x.Foo(0, 0), 
    x => x.IgnoreArguments()
);
var int = (int)args[0][1];
    InformationsquelleAutor Darin Dimitrov
  2. 0

    Nicht sicher, ob es getan werden kann, aber Tests wie können dazu führen, dass unzuverlässige tests, da Sie nicht wissen, die tatsächlichen Parameter, die übergeben wurde.

    Wenn möglich, testen Sie auf explizite Daten. Wenn Sie die f.eks-übergeben Sie null anstelle von einem realen Wert Ihres test wird wahrscheinlich pass für den falschen Grund.

    Tests mit Arg.Ist.Alles sollte sorgfältig durchgeführt werden und wenn Sie wirklich kümmern sich nicht um die parameter, wie in AssertWasNotCalled.

    • Ich bin nicht einverstanden mit Ihnen. Um mal ein Beispiel ich habe einen service-proxy, ich zu Verspotten. Ich pflanze diesen service proxy beim erstellen eines Objekts foo der Klasse, die Sie benutzen. Ich habe dann rufen Sie eine Funktion auf dem Objekt foo, und ich erwarte, dass diese Funktion zum aufrufen einer Funktion über die service-proxy-mock mit einigen Argumenten, die ich erwarte, und auch eine callback-Funktion, die für die Klasse privat. Jetzt möchte ich überprüfen, dass die Funktion aufgerufen wurde, mit der erwarteten Argumente, aber ich kann nicht überprüfen Sie für den privaten Rückruf, und daher festlegen, Arg.Ist.Nichts. Ich kümmern sich nicht um das argument, warum sollte ich also nicht?
    • Ahh ich sehe. Ich hatte einige Probleme testen callbacks und Lambda-Ausdrücke als auch. Ich kam zu dem Schluss, dass mein design falsch war. Die schöne Sache über die Prüfung, und vor allem TDD ist, dass es Ihnen sagt, wenn Ihr design ist falsch. Ob oder nicht dein design ist falsch, ich kann Ihnen nicht sagen, aber wenn Sie feststellen, dass Ihr code ist schwierig zu testen, sollten Sie vielleicht überdenken Sie Ihre design.
    InformationsquelleAutor Henning
Schreibe einen Kommentar