2017-01-23 5 views
1

Ich habe eine Funktion in Winkel 2 Service, die ich testen möchte.Fake ein Modul in Winkel 2 Test

service.ts

upload(){ 
    let file = new Transfer(); 
    file.upload(myfile).then(// my callback); 
} 

würde Ich mag Transfer in meinem Test verspotten jasmine verwenden. Ich habe versucht, dies in meinem

sevice.spec.ts

import { TransferMock as Transfer } from '../mocks/mocks' es zu verspotten. Aber es funktioniert nicht. So wird mein Test instanziiert.

describe('authentication service' ,() => { 
    beforeEach(() => { 
    auth = new Service(<any>new HttpMock(), <any>new StorageMock()) 
    }); 
    it('initialize authentication',() => { 
    expect(auth).not.toEqual(null); 
    auth.upload('file'); //it fails here 
    }); 
}) 

bearbeiten

Transfer wird in den Dienst nicht injiziert. Nur eine Funktion verwendet Transfer. Also nicht injizieren kann die anfängliche Ladezeit der App zu reduzieren, denke ich (wäre glücklich, andere Meinungen zu wissen). Also ich würde gerne wissen, ob es überhaupt zu verspotten gibt, wenn es so gebaut wird?

bearbeiten

Obwohl ich Martins Antwort akzeptiert hatte, da es die beste Praxis ist, hat es ein Problem, das, wenn Sie ionic-native plugins.If Plugin muß nicht Browser-Unterstützung haben kann es nicht verwenden passieren kann. In diesem Fall ist es passiert, wenn ich es injiziere, mit Fehler FileTransfer is not defined. Also bin ich wieder zurück und suche nach Vorschlägen.

Antwort

4

Um einen Test für eine Klasse in einem Test bereitzustellen, müssen Sie die Klasse in Ihrer Implementierung injizieren.

In Ihrer ngModule fügen Sie Transfer zu Ihren Providern hinzu. Dann injiziere es einfach in deinen Dienst.

Dann können Sie in Ihrem Test { provide: Transfer, useClass: TransferMock } in Ihrem TestBed Provider verwenden.

aktualisieren

Der primäre Zweck der Dependency Injection ist Code testbar zu machen und spöttisch zu ermöglichen - Fälschen - Anstoßen von Dienstleistungen.

aktualisieren

Mit Dependency Injection können Sie einen anderen Satz von Anbietern für verschiedene Umgebungen konfigurieren.

Wenn Sie beispielsweise Ihre Anwendung im Browser ausführen und in einer nativen mobilen Umgebung können Sie Ihre Konfiguration austauschen.

In Ihrem Modul könnten Sie so etwas wie diese:

const TRANSFER_PROVIDER: any; 

if (environment.browser) { 
    TRANSFER_PROVIDER = Transfer; 
} else { 
    TRANSFER_PROVIDER = { provide: Transfer, useClass: NativeTransfer } 
} 

... 
providers: [ TRANSFER_PROVIDER ] 

NativeTransfer könnte eine einfache Stub sein, der nichts tut, aber Fehler zu vermeiden, oder es könnte der Benutzer weiß, dass diese Funktion nicht in ihrem Browser unterstützt wird .

+0

Danke Martin für schnelle Antwort.'' Transfer'' wird nicht in meinen Dienst eingefügt, wie ich in meiner Frage erwähnt habe. Nur eine Funktion verwendet '' Transfer''. Also nicht injizieren kann die anfängliche Ladezeit reduzieren, die ich denke (?). Also ich würde gerne wissen, ob es überhaupt zu verspotten gibt, wenn es so gebaut wird? – raj

+1

Nein. Sie sollten es so machen wie von Martin erwähnt. Es gibt keinen Nachteil, den Transfer in Ihren Dienst zu injizieren ... selbst wenn es nur in einer Methode verwendet wird. Dies ist ein allgemeines Muster. – philipooo

+0

@raj Durch die Verwendung von Dependancy Injection wird kein Leistungseinbruch erzielt. Stattdessen haben Sie den Vorteil von testbarem Code. – Martin