Können/sollten benutzerdefinierte $ Ressourcenaktionsmethoden getestet werden?

Question

In einem Winkeldienst habe ich $ resource Aktionsmethoden wie:

class FooService { 
    /*@ngInject*/ 
    constructor($resource) { 
    this.Foo = $resource('/foo/:fooId/', 
          {fooId: '@fooId'}, 
          { 
          bar: { 
           method: 'GET', 
           url: '/foo/:fooId/bar/', 
           isArray: true 
          } 
       ); 
    } 
    getAllFoo() { 
    return this.Foo.query(); 
    } 
} 

ist prüfbar Bar?

Ich habe bereits Tests für Methoden wie getAllFoo(), aber ich bin nicht so sicher über $ Ressourcenaktionsmethoden.

Ist es in Ordnung, sie direkt in der Steuerung zu verwenden, wie in
this.FooService.Foo.bar(params).$promise.then?

Sollten sie getestet werden? Und wenn ja, wie?

EDIT: Ich weiß, wie getAllFoo zu testen():

describe('FooService',() => { 
    let $rootScope, $resource, $httpBackend, $log, $interval; 
    let makeFooService, translateMock; 
    let mockAllFoo = [ 
     {"id": 123,"stuff": "asdf asdf"}, 
     {"id": 124,"stuff": "hjghjg"} 
    ]; 

    beforeEach(window.module(FooModule.name)); 

    beforeEach(inject((_$rootScope_, $q, _$resource_, _$httpBackend_, _$log_) => { 
     $rootScope = _$rootScope_; 
     queryDeferred = $q.defer(); 
     $resource = _$resource_; 
     $httpBackend = _$httpBackend_; 
     $log = _$log_; 
     translateMock = { use:() => ({}) }; 
     makeFooService =() => new FooService(_$resource_); 
    })); 

    afterEach(function() { 
     $httpBackend.verifyNoOutstandingExpectation(); 
     $httpBackend.verifyNoOutstandingRequest(); 
    }); 
    describe('Service',() => { 
    it('has a resource-property [Foo]',() => { 
     let service = makeFooService(); 
     expect(service.Foo).not.toBeNull(); 
    }); 

    it('should load all foos when getAllFoo() is called',() => { 
     $httpBackend.expect('GET', /(.+)\/foo/).respond(() => [200, mockAllFoo, 'success']); 
     let service = makeFooService(); 
     let allFoo = service.getAllFoo(); 
     $httpBackend.flush(); 
     expect(allFoo.length).toBe(2); 
    }); 

So weiß ich, wie getAllFoo zu testen(), aber nicht, wie bar zu testen(); Wenn bar ist testbar und in einem Controller direkt verwendbar, dann sehe ich nicht den Punkt der Methoden wie getAllFoo(), die einfach um $ Ressourcen Aktion Methoden Wrapper sind. Ich brauche hier Erläuterungen zu den Best Practices.

Answer 1

Ich denke, es ist eine gute Idee Testressourcen, einige Ressourcen können Antworttransformatoren oder eine Logik haben, um die URL-Anfrage zu erstellen. Angular stellt $ httpBackend für den Performer-Test in http-Anfragen bereit, die die HTTP-Antwort vortäuschen können.

Mock die Anfrage

$httpBackend.when('GET', '/foo').respond({foo: 'bar'}, {'A-Token': 'xxx'}); 

der HTTP-Antwort Ausgabe

$httpBackend.flush(); 

https://docs.angularjs.org/api/ngMock/service/$httpBackend

Ja, in meiner Option gibt es keine erforderlich, um eine "Wrapper" nur zu erstellen, wenn Sie tun müssen, einige Logik vor Aufruf der eigentlichen Ressource.

Um „bar“ zu testen, werden Sie etwas ähnlich den folgenden Code tun müssen:

it('should call the correct url and handler the response right', (done)=>{ 
    $httpBackend.expect('GET', '/foo/bar_id/bar/').respond(() => [200, {'id': 124,'stuff': 'hjghjg'}, 'success']); 
    let service = makeFooService(); 

    service.bar({fooId: 'bar_id'}).$promise.then(result =>{ 
     expect(result).toEqual({'id': 124,'stuff': 'hjghjg'}); 
     done(); 
    }); 
    $httpBackend.flush(); 
}); 

Auch ich denke, es die Ressource-Methode direkt aus der Steuerung in Ordnung Anruf ist. $ Ressource stellt eine bestimmte Funktionalität, die Sie nicht brauchen, das Versprechen zu behandeln, können Sie den Antwortwert direkt mit einem var wie zuweisen:

var bar = this.FooService.Foo.bar(params); 

https://docs.angularjs.org/api/ngResource/service/$resource