Flutter-geolocator: Ich hasse statische Methoden wirklich ...

@jaumard Ich gebe zu, dass dies vielleicht nicht die beste Wahl war, die ich getroffen habe. Zu meiner Verteidigung legt jedoch die gängige Praxis beim Testen und der Anwendungsarchitektur im Allgemeinen nahe, dass Sie sich nicht über etwas lustig machen sollten, das Sie nicht besitzen (mehr zum Lesen hier ).

Mein Vorschlag wäre, einen Wrapper um den Geolocator zu schreiben und stattdessen den Wrapper zu verspotten.

Bei Ihrem Link geht es mehr um TDD als um Unit-Tests im Allgemeinen. Auch wenn wir es nicht verspotten, wird der Test nicht bestanden, nehme ich an, weil es beim Ausführen des Tests keine Implementierung gibt.

Außerdem möchte ich überprüfen, ob die Geolokalisierung in meinem Code aufgerufen wird, und überprüfen, was ich mit dem Ergebnis mache, ist korrekt. So viele Gründe, warum Sie Deps von Drittanbietern verspotten möchten :)

Machen Sie sich auch nicht über das Netzwerk lustig und führen Sie Ihre Tests ohne Netzwerk durch, es wird Spaß machen :D oder sogar mit Real Show Network und Sie haben 1 Stunde Zeit, um Ihre Tests auszuführen, lol

Aber ja, ich mache meinen eigenen Wrapper um den Geolocator und frage mich nur, ob etwas eingebaut wurde, bevor ich es tat.

Der Link schlägt auch vor, Wrapper/Adapter/Shims für Abhängigkeiten von Drittanbietern zu erstellen und diese stattdessen aus den von Ihnen genannten Gründen zu verspotten. Auf diese Weise verspotten Sie nur Code, den Sie besitzen (da Sie der Eigentümer der Wrapper / Adapter / Shims sind).

Dies hat folgende Vorteile:

• Abstrahiert die Drittanbieter-API, wodurch sie bei Bedarf leichter ersetzt werden kann;
• Reduziert die Oberfläche der API auf nur die Teile, die Ihre Anwendung benötigt, wodurch die API einfacher zu verwenden und vom Rest Ihrer Anwendung zu verstehen ist;
• Beeinträchtigt nicht alle Ihre Tests, wenn sich die Drittanbieter-API ändert.

Ich werde dieses Thema schließen, aber Sie können die Diskussion gerne fortsetzen ;)