2016-05-02 9 views
5

Ich habe gerade meine ersten Komponententests in AngularJS über Jasmine geschrieben.

Irgendwie verstehe ich immer noch nicht, warum ich das $ httpBackend verspotten sollte. Um deutlich zu machen, was mir noch unklar ist, werde ich ein kleines Beispiel aufschreiben:

Stellen Ich habe ein Service(myService), die Daten von einer URL wird immer:

function getData() { 
    return $http.get("http://example.com/data") 
     .then(function (response) { 
      return response.data; 
     }); 
} 

Nehmen wir an, dass ein GET an die URL aufrufen "http://example.com/data" liefert folgende Daten:

{ 
    firstname: "John", 
    lastname: "Doe" 
} 

die entsprechende Test würde wie folgt aussehen:

describe("Service: myService", function() { 

    beforeEach(module("myApp")); 

    var myService, $httpBackend; 

    beforeEach(inject(function (_myService_, _$httpBackend_) { 
     myService = _myService_; 
     $httpBackend = _$httpBackend_; 
    })); 

    afterEach(function() { 
     $httpBackend.verifyNoOutstandingExpectation(); 
     $httpBackend.verifyNoOutstandingRequest(); 
    }); 

    it("should get data", function() { 
     var mockData = {datakey: "datavalue"}; 
     $httpBackend.whenGET("http://example.com/data").respond(mockData); 

     var promise = myService.getData(); 
     $httpBackend.flush(); 

     promise.then(function(response){ 
      expect(response).toEqual(mockData) 
     }); 
    }) 
}); 

Wenn ich nicht irre, sollte der Test bestehen, obwohl die verspottete Daten nicht gleich den realen Daten ist. Der Test würde immer bestehen, egal wie ich die mokierten Daten einstelle, weil die Service-Funktion immer zu dem weitergeleitet würde, was in $ httpBackend.whenGET gesetzt ist ("http://example.com/data") .respond (mockData);. wenn die zurückgegebenen Daten von einem GET Anruf

Ich dachte, der Zweck eines solchen Tests zu überprüfen ist, [in diesem Fall myService.getData()] wirklich die erwarteten Daten und nicht einige zufällige verspott Daten. Also, was ist der eigentliche Punkt der Mocking Daten, anstatt zu überprüfen, ob myService.getData die realen Daten {Vorname: "John", Nachname: "Doe"}?

Ich bin mir bewusst, dass ich auch die verspottete Daten zu {Vornamen: „John“, Nachnamen: „Doe“} einstellen könnte, aber wenn die realen Daten aus der URL dynamisch sein würden, Daten des verspottet und die realen Daten wären nicht wieder gleich.

Vielen Dank im Voraus!

+1

Sie stellen sicher, dass Sie die gute URL anrufen. –

Antwort

3

Sie haben irgendwie zu unterscheiden zwischen:

  • Unit-Tests
  • Integrationstests
  • End-to-End-Tests

Was Sie wollen, ist zu Unit-Test des getData() Funktion. Ich nehme an, es ist dir egal, ob die Daten in diesem Fall stimmen oder nicht. Was Sie wollen zu testen ist, wenn die richtige URL aufgerufen wird.

So stellen Sie sicher, dass diese Einheit Ihres Codes wie erwartet funktioniert.

Nehmen Sie dieses Beispiel:

var add = function(endpoint) { 
    var sum = 0; 
    endpoint().then(function(numberArray) { 
    numberArray.forEach(number) { 
     sum = sum + number; 
    } 
    }); 

    return sum; 
}; 

Wenn Sie die httpBackend hier verspotten, Sie kümmern sich eigentlich nicht, wenn Sie eine 1,2,3 oder 5,6,7 zurück.Sie möchten sicherstellen, dass Sie eine beliebige Zahl hinzufügen, addieren und addieren.

Ihr Fall ist viel einfacher, so dass Sie testen können, ob die URL richtig ist, und das ist es.

Ein Ende-zu-Ende-Test würde auch ein korrektes Backend beinhalten und prüfen, ob die Daten in Ordnung sind.

Die AngularJS documentation macht deutlich:

it('should fetch authentication token', function() { 
    $httpBackend.expectGET('/auth.py'); 
    var controller = createController(); 
    $httpBackend.flush(); 
}); 

In diesem Beispiel Sie sicherstellen möchten, dass Sie die richtige URL/Endpunkt anrufen. Wenn Sie wirklich das richtige Token bekommen, ist ein Integrationstest oder End-to-End-Test angemessener, der dann das echte Backend aufruft.

+0

Also, wann immer ich HTTP GET-Anfragen in einem Komponententest testen, ist das Ziel zu überprüfen, ob die richtige URL aufgerufen wird und nicht, wenn die richtigen Daten gesetzt werden? –

+0

Aus meiner Erfahrung und meinen Lesungen, ja! Ein Komponententest bedeutet, dass Sie die Funktionalität einer Funktion, einer Einheit Ihrer Anwendung, testen. Wie die Daten aussehen ist meistens nicht Teil davon, da die Funktion darauf reagieren sollte (werfen Sie Fehler usw.) –

+0

Vielen Dank für Ihre Zeit. Aber ich frage mich immer noch, warum jemand (wie in vielen Tutorials zu $ ​​httpBackend) Mock-Daten verwendet und diese mit den Daten der entsprechenden Funktion vergleicht, die die http-Anfrage macht, anstatt nur zu prüfen, ob die URL aufgerufen wird oder nicht (wie in Ihrem Beispiel oben). Hier ein Plunker, um zu demonstrieren, was ich meine: http://plnkr.co/edit/XcWySIWtIJ3QCIOB0iJB?p=info –