Getting Unknown Provider error when injecting a Service into an Angular unit test

I just ran into this and solved it by switching to getting the service using the $injector explicitly:

var EventingService, $rootScope;beforeEach(inject(function($injector) {  EventingService = $injector.get('EventingService');  $rootScope = $injector.get('$rootScope');}));

I wish I could tell you why this works and why the simple

beforeEach(inject(function(EventingService) {   ....  }));

does not, but I don't have the time to investigate the internals. Always best to use one coding style and stick to it.

This style is better in that the name of the variable that you use in your tests is the correct name of the Service. But it is a bit verbose.

There is another angular magic feature that uses strange variable names like $rootScope but I don't like the hacky look of that.

Note that the most of the time people get this error because they didn't include the modules:

beforeEach(module('capsuling'));beforeEach(module('capsuling.capsules.services'));

If your controllers (defined under dashboard.controllers module) depend on some services which are enclosed in different module (dashboard.services) than you need to reference the dependency modules in your module signature:

angular.module('dashboard.services', []);angular.module('dashboard.controllers', ['dashboard.services']);

While this question is fairly old i lost significant time solving a problem similar to this one, i.e.:

Error: Unknown provider: SomeServiceProvider <- SomeService

Hence, i'm leaving here another possible cause to this issue. Hopefully, it would helpful to someone.

In my case, i had in my project two modules with the exactly same name but with different dependencies being created, i.e., two different .js files with:

angular.module('moduleName', [dependencies]))

From angular documentation:

Passing one argument retrieves an existing angular.Module, whereas passing more than one argument creates a new angular.Module

Conclusion: It turns out that what was being injected in the test was the module with the wrong dependencies. Removing the second argument from the module that was erroneously being created solved the problem.