default route templateUrl causes unexpected GET error in all module unit test specs

[jardilio]

I have an application that is broken down into several modules, each of which defines its own routes to handle and contains several controllers, services...all thru separate files which register themselves to the appropriate module(s).

When I create unit test specs for any particular service, I hit an issue where I get an 'expected GET' request as a result of a templateUrl linked to the default route in the module. I don't expect to have to write an expect in every spec for the route which is completely unrelated to the controller, service, directive...which I am unit testing.

I have created a plunk to test the situation here: http://plnkr.co/edit/jfetatSfBguwEGT59QJ4?p=preview

The actual combination of items that cause such a situation are as follows:

1. Create a default route for path '/' AND give it a templateUrl value (using template is not an issue)
2. Somewhere in your module chain for which you are unit testing, contain a reference to the $route service

When the above criteria are met, there isn't a good way to separate the unit tests since the module configuration defines route mapping and modules reference to $route initialize code behind the scenes to begin loading the default routes templateUrl thus creating an unexpected GET request for the templateUrl.

The only workaround I have is to explicitly place an $httpBackend.expectGET('path/to/default/template.html') in every test that uses this module reference, but this is not expected and completely unrelated to the test itself.

[aeby]

Any updates on this?

[petebacondarwin]

This is expected behaviour. By providing a route that maps to the current URL you expect the $route service to try to get the template specified in the route by making a GET request. There are a number of ways to handle this situation.

1. provide a $httpBackend response for this template
2. preload the $templateCache service with content for this template
3. mock out the $route service in your tests
4. don't reference the $route service in the aspect of the module under test or in the tests themselves. In particular not in a run() block.

I would go with the last option, if possible. It should not be necessary to reference the $route service in a run() block for your module. You can reference the $routeParams service safely. All references to $route should be inside services that specifically rely upon the $route functionality. In those cases, for your unit test you should expect this call to get the template, so probably use one of the first two options.

[jardilio]

So, for anyone else that runs into a similar situation. My problem is that I have a redirectProvider I created which is used in conjunction with a routeProvider. Its a helper that creates redirect rules based on authentication, watches for authentication changes and when that happens, would call $route.reload() to re-process the redirect rules for the given route.

My "fix" is to rather than directly inject "$route" in a run script for this provider is to instead require "$injector" and only on the first time I need to call a reload, then fetch $route from $injector. This prevents $route from being processed until its needed and that will only happen if $route is referenced by something else in the application (like using the ng-view directive).

[shuhaowu]

Wait. So does that mean if you inject $route via the ["$route", function($route)] it will cause a template load?

Isn't that a bug for testing? Injecting $location does not seem to trigger this.

[caitp]

injecting $route does not cause a template to load, by itself. There was a change at some point which (I think, not positive) would have caused this, but it was reverted by 3085987#diff-34e732507a1b6941aaf4ae5084a7c6ca... so this would never have been available in a release.

So most likely you don't have to worry about that.

[jardilio]

Correct that it won't occur by referencing $route by itself, but when you also define a default route ("/") with a templateUrl. In the case mentioned, this was the situation and since the unit tests ran on a base/root URL, referencing $route would cause the route "/" to be processed and attempt to load the linked template.

This was all previously tested in release code (v1.0.6) as shown in the linked plunker.

[christophefondacci]

+1 It is a nightmare to have any $route dependency anywhere in a code with unit tests.

My service has a $route dependency, it is a top-level service and almost nothing depends on it except html views. But as soon as you have the $route declared as a dependency (even with no code calling it), you have a "/" processed, resulting in an unexpected get (when mapped from $routeProvider, which is also my case).

Since the / is fired when the $route is injected, EVERY test with a $httpBackend.flush() fails. It is not possible to isolate this, I have to mock $route in all my tests, even unrelated, or to expect this "/" request.

@caitp it is really available in a release, I am using 1.2.18 here.

The only viable option is to rely on $injector as @jardilio suggested so that I only have to expect that call when it is used.

[jardilio]

@christophefondacci you can also preload all templates into $templateCache to prevent the unexpected gets as well. If you are using karma, there is a preprocessor for this:

https://github.com/karma-runner/karma-ng-html2js-preprocessor

This is also good if you are testing directives that load templates.