Testing custom provider

[0x-r4bbit]

Is there anyway to get an instance of a specific provider in unit tests to test it?
I'm currently writing a custom provider and want to test it through unit tests, but there seems to be no way to that.

You can do this to configure a provider in unit tests:

...
it('spec', function () {
    module(function ($providerInstance) {
        $providerInstance.any():
    }));
});
...

Or pass module() directly as callback:

...
it('spec', module(function ($providerInstance) {
    $providerInstance.any():
})));
...

But then you're not in the right scope to use your test frameworks test methods. So this:

...
it('spec', module(function ($providerInstance) {
    $providerInstance.any():
    expect(true).toBe(false);
})));
...

Will always pass successfully.

So is there any way (maybe with angular.mocks) to get access to a provider instance in unit tests? Or shouldn't one be able to test providers, cause in code you actually deal with service instances?

[joshdmiller]

I struggled with this same question and ultimately concluded that if we assume that the philosophy of a provider is only configuration then it makes more sense in most cases to test that "it" is configured. As the "it" in this case is the resulting service, using module to do the configuration and then inject to test that the configuration worked seems to make sense.

E.g.:

it( 'should follow option set', function () {
  module( function ( $whateverProvider ) {
    $whateverProvider.options({ myProp: true });
  });

  inject( function ( $whatever ) {
    expect( $whatever.doSomething() ).toBehaveAsConfigured();
  });
});

This is also how some official services are tested, like $routeProvider.

[0x-r4bbit]

Yeap. I also came across this "solution" which actually isn't one. After thinking about it a longer time, I had the same thought, that one has to test a configured provider through the public api of the service you get from it.

I also took a look at angular.js source to see how they do it (coincidentally the $routeProvider). So, actually I'm okay with this, but currently I have the case where my custom provider throws an error in a specific case when using a public method to configure it during angular.module('myApp', []).config(function () { .... });.

And this is a situation where I really would like to test, if the error gets thrown or not.

[charleskilbourne]

I'm having the same problem

if you look here (http://docs.angularjs.org/api/AUTO.$provide)

this test in the official api reference works as expected, but I'm having problems accessing my provider that is defined in a module

[joshdmiller]

@charleskilbourne - In the API docs, the tests are run against the created module rather than against the provider. If you registered your module with .provider('...', function () {...}), you shouldn't need to use the $provide method in your tests.

The problem we're having is wanting to run expects on the provider itself.

[joshdmiller]

@PascalPrecht Okay, solved! As it turns out, it's awfully silly we didn't see it, but Vojta set me straight:

describe('Testing a provider', function() {
  var p;

  beforeEach(module('plunker', function( myServiceProvider ) {
      p = myServiceProvider;
  }));

  it('should return true on method call', inject(function () {
    expect(p.method()).toBeTruthy();
  }));
});

It's not often I feel dumb, so I'll have to savor the experience. Here's a Plunker: http://plnkr.co/edit/UkltiSG8sW7ICb9YBZSH

[MikeMcElroy]

Just to make you feel more dumb, you don't need that extra inject() for
your test. It's only beneficial if you were injecting another dependency.
:-)

--MikeMac
On Apr 4, 2013 8:35 PM, "Josh D Miller" notifications@github.com wrote:

@PascalPrecht https://github.com/PascalPrecht Okay, solved! As it turns
out, it's awfully silly we didn't see it, but Vojta set me straight:

describe('Testing a provider', function() {
var p;

beforeEach(module('plunker', function( myServiceProvider ) {
p = myServiceProvider;
}));

it('should return true on method call', inject(function () {
expect(p.method()).toBeTruthy();
}));});

It's not often I feel dumb, so I'll have to savor the experience. Here's a
Plunker: http://plnkr.co/edit/UkltiSG8sW7ICb9YBZSH

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/2274#issuecomment-15937508
.

[0x-r4bbit]

@joshdmiller Damn it! Of course! Thanks man! :D Will close it for now.

[0x-r4bbit]

Okay. Testing your plunker with my code works as well. Running the same code with karma (and jasmine) doesn't work.

var p;

beforeEach(module('myModule', function ($myProvider') {
    p = $myProvider;
}));

it('should fucking work', function () {
    expect(p).toBeDefined();
});

The weird thing: p is always undefined. And again, in your plunker the code works. Any ideas on that?

[joshdmiller]

@MikeMcElroy Actually, that was intentional. I wanted to ensure the test was running after the config stage and confirming the injector was available was the easiest way. But thanks for attempting to humble me - you'll have to try harder next time as I've rebounded and my ego is again quite healthy.

@PascalPrecht It seems to work for me...I just added a test to an existing project against the provider and all is well. Since we're all being dumb here, I'll start with a dumb question: since you're requesting $myProvider, your service is called $my and is otherwise injectable, right?

[0x-r4bbit]

Yeap everything work fine except, that assigning a provider value within beforeEach(module() {})); doesn't work. It works in your plunker. Even with my code. But not in my environment when runnting the tests with karma. I'm not sure if its a karma-jasmine-adapter-angular-mock-thingy which stands in my way?

[ggalmazor]

I'm exeperiencing this same problem. I've prepared a complete spec in a gist that involves third party dependencies and a config phase for the provider. One should be able to test a provider like a controller or service...

https://gist.github.com/ggalmazor/5419813

[nprbst]

Hopefully this helps...it works for me.

The trick is to realize that the function passed to module() does not get called until inject() does it's thing. So assigning to a closure variable in the module initialization function ensures that the Provider is defined before control passes to the injected function. Then you're free to interact with the Provider's configuration interface. The technique is a little bit broken in that the Provider has already provided it's Service. But, if you can tolerate that limitation (I can) it works OK.

  it('should throw if a state is redefined', function() {
    var stateProvider;
    module(function($stateProvider) {
      stateProvider = $stateProvider;
    });
    inject(function($state) {
      stateProvider.state('foo', {});
      expect(function() {
        stateProvider.state('foo', {});
      })
      .toThrow("[npState:dupstate] You may not redefine the existing state: 'foo'");
    });
  });

[laurelnaiad]

Thanks, @nathanprobst, that's helpful.

The technique is a little bit broken in that the Provider has already provided it's Service.

I guess that, if one assumes that in the provision of the service there are no side-effects on the (testable portions of the) provider-level state, then it is completely tolerable.

Note to self: don't have the $get function altering provider state if you want to test the provider. This should be doable in general. If, in an edge case, the service does need to modify provider state, ensure that it is done through calls to the service and not on its instantiation. (One would obviously not make such calls when testing the provider.)