Verblüfft man eine statische Klassenmethode in einem schnellen Komponententest?

Question

Verblüfft man eine statische Klassenmethode in einem schnellen Komponententest?

9

Ich bin ein erfahrener Objective-c-Programmierer, aber ich kann nicht das Gleiche für Swift sagen, ich habe eine harte Zeiteinheit, die eine Klasse in swift testet, ohne Frameworks wie OCMock zu verwenden.

Das Problem : Ich integriere Firebase in ein gemischtes Objective-C / Swift-Projekt und muss es basierend auf der Build-Konfiguration der App konfigurieren.

Ich habe eine Swift-Klasse dafür geschrieben (die vom obj-c-App-Delegaten verwendet wird), aber da das Firebase-Framework über eine statische Klassenmethode konfiguriert ist, genau FIRApp.configure(with: FIROptions) , muss ich diese Methode vortäuschen irgendwie um es zu testen.

Mein Code ohne Handle für Dependency Injection sieht so aus:

%Vor%

Ich habe einige Nachforschungen angestellt, aber bis jetzt habe ich nichts gefunden, was zu meiner Lösung passt, aber ich habe an eines der folgenden Dinge gedacht:

Ich könnte eine Funktion übergeben, die standardmäßig FIRApp.configure(with:) ist, aber ich sollte dies von objective-c tun und die Funktion akzeptiert auch einen Parameter, ich habe mit der Syntax
Ich könnte einen Wrapper rund um FIRApp verwenden, aber ich wollte es vermeiden, es sei denn, die einzige brauchbare saubere Lösung.
Ich könnte weiter mit Protokollen spielen und Abhängigkeitsinversion machen, aber da die Methode statisch ist, hatte ich wieder mit der Syntax zu kämpfen, ich kann keinen einfachen Weg finden, DI mit einer Scheinklasse mit einer statischen Methode zu machen.

Als Referenz (sowohl persönlich als auch für diejenigen, die es brauchen könnten) sind dies einige der Ressourcen, die ich nützlich fand und auf denen ich weiter graben werde:

In der Zwischenzeit wird jede Hilfe sehr geschätzt.

Als Nebenbemerkung gibt es viele Möglichkeiten, wie ich dieses Problem lösen kann, ohne mich mit einer statischen Klassenmethode herumärgern zu müssen, aber mein Ziel ist es, eine Art zu verspotten, um die Best Practices besser zu verstehen komplexere Situationen testen.

unit-testing dependency-injection swift swift-protocols xctest

dev_mush 11.02.2017, 00:12

quelle

1 Antwort

Tags und Links unit-testing dependency-injection swift swift-protocols xctest

Django: Verwenden von Annotate, Count und Distinct in einem Queryset Sekundäre Konstruktionssyntax kotlin

score 3 · Accepted Answer

Sie können tatsächlich jeden von denen tun.

Closure-Argument

Sie können festlegen, dass Ihre configureFirebase -Funktion eine "Anwendungs" -Schließung verwendet, die standardmäßig auf die ursprüngliche verwendet wird:

%Vor%

Protokolle

Sie benötigen ein Configurable -Protokoll und passen es dann für den Standardfall FIRApp an:

%Vor%

Wenn Sie dies nur in einer Methode verwenden, ist es lediglich ein Übergangszustand, und es sollte wahrscheinlich ein Funktionsargument und keine gespeicherte Eigenschaft sein.

(Wenn unklar ist, ob es sich um einen persistenten oder transienten Zustand handelt, weil der ganze Sinn der Klasse darin besteht, eine einzelne Funktion aufzurufen, brauchen Sie vielleicht gar keine Klasse, nur eine Funktion.)