Ich verwende GWTP und füge eine Contract-Schicht hinzu, um das Wissen zwischen Presenter und View zu abstrahieren, und ich bin ziemlich zufrieden mit dem Ergebnis von GWTP. Ich teste meine Moderatoren mit Mockito.
Aber mit der Zeit fand ich es schwierig, einen sauberen Moderator mit seinen Tests zu halten. Es gibt einige Refactoring-Sachen, die ich getan habe, um das zu verbessern, aber ich war immer noch nicht zufrieden.
Ich fand Folgendes das Herzstück der Sache: Meine Moderatoren benötigen oft einen asynchronen Aufruf oder rufen im Allgemeinen die Methode objects mit einem Callback auf, um meinen Presenter-Flow fortzusetzen (sie sind normalerweise verschachtelt).
Zum Beispiel:
%Vor%In meinen Tests habe ich beendet, um den population () -Aufruf des verspotteten PopulationManager-Objekts zu überprüfen. Dann um einen weiteren Test für die Methode doSomeStufWithTheView () zu erstellen.
Aber ich habe recht schnell festgestellt, dass es ein schlechtes Design war: Jede Änderung oder Refactoring beendete viele meiner Tests und zwingt mich, von Anfang an andere zu erstellen, obwohl sich die Moderatorfunktionalität nicht änderte! Außerdem habe ich nicht getestet, ob der Rückruf wirklich das war, was ich wollte.
Also habe ich versucht, die Methode "Misto doAnswer" zu verwenden, um meinen Presenter-Testfluss nicht zu unterbrechen:
%Vor%Ich habe den Code für weniger ausführlich (und weniger abhängig von der Arg-Position) berücksichtigt:
%Vor%Also, während ich den populationManager verspottete, konnte ich immer noch den Fluss meines Moderators testen, im Prinzip so:
%Vor%Ich frage mich, ob es eine gute Verwendung der DoAnswer-Methode ist, oder ob es ein Code-Geruch ist und ein besseres Design verwendet werden kann?
Normalerweise tendieren meine Moderatoren dazu, andere Objekte (wie ein Mediator-Muster) zu verwenden und interagieren mit der Ansicht. Ich habe einen Präsentator mit mehreren hundert (~ 400) Zeilen Code.
Ist es wieder ein Beweis für ein schlechtes Design, oder ist es normal, dass ein Moderator ausführlich ist (weil er andere Objekte verwendet)?
Hat jemand von einem Projekt gehört, das GWTP verwendet und seinen Moderator sauber testet?
Ich hoffe, ich habe es ausführlich erklärt.
Vielen Dank im Voraus.
PS: Ich bin ziemlich neu in Stack Overflow, und mein Englisch fehlt noch, wenn meine Frage etwas verbesserungsbedürftig ist, bitte sag es mir.
Sie könnten ArgumentCaptor verwenden:
Schauen Sie sich diesen Blogbeitrag für weitere Details an.
Wenn ich richtig verstanden habe, fragen Sie nach Design / Architektur.
Dies sollte nicht als Antwort gezählt werden, es sind nur meine Gedanken.
Wenn ich Code gefolgt bin:
%Vor%Ich zähle normalerweise nicht auf den Executor und überprüfe einfach, dass die Methode einen konkreten Job durch Laden und Speichern ausführt. Der Executor ist also nur ein Instrument, um lange Operationen im UI-Thread zu verhindern.
Wenn ich etwas wie:
habe %Vor% Ich werde zuerst überprüfen, ob wir Ereignisse abonniert haben (und bei einigen zerstörten Abonnements abbestellt haben), und ich würde prüfen, ob onAccountEvent erwartete Szenarien erfüllt.
UPD1. In Beispiel 1 wäre es wahrscheinlich besser, die Methode loadFromServerAndSave zu extrahieren und zu überprüfen, ob sie auch im UI-Thread ausgeführt wird und ob alles wie erwartet ausgeführt wird.
UPD2. Es ist besser, Framework wie Guava Bus für die Ereignisverarbeitung zu verwenden.
Wir verwenden dieses doAnswer-Muster auch in unseren Presenter-Tests und normalerweise funktioniert es gut. Ein Nachteil: Wenn Sie es so testen, entfernen Sie effektiv die asynchrone Natur des Anrufs, dh der Rückruf wird unmittelbar nach dem Server-Aufruf ausgeführt.
Dies kann zu unentdeckten Rennbedingungen führen. Um dies zu überprüfen, können Sie dies in zwei Schritten durchführen: Beim Aufrufen des Servers speichert die Antwortmethode nur den Rückruf. Dann, wenn es in Ihrem Test angemessen ist, rufen Sie etwas wie flush () oder onSuccess () auf Ihre Antwort (ich würde vorschlagen, eine Dienstprogramm-Klasse für diese, die in anderen Umständen wiederverwendet werden können), so dass Sie steuern können, wenn Callback für das Ergebnis wird wirklich aufgerufen.
Tags und Links gwt testing mockito gwt-platform