Why angular module's factory method should be redefined in the test mock

Question

in an angular.js tutorial , i found this example of a factory testing :

the module :

angular.module('omdbModule', [])
    .factory('omdbApi', function omdbApiFactory() { 
          return { 
              search: function() {
                 //logic to get data return movieData;
          }
    }

the test (it can be made by two ways : passing an anonymous function with '$provide' as an argument :

 angular.mock.module(function($provide){
         $provide.factory('omdbApi', function(){ 
             return{
                search:function(query){
                  return movieData;
              }
         }
    });

or just using an object literal :

 angular.mock.module({
         'omdbApi':{
              { search:function(query){
                  return movieData;
              }
         }
    });

in both cases i don't understand why the search function had to be redefined in the mock instead of just getting the factory and then automatically access all its properties and methods. I think defining the whole factory in a mock is good in case it doesn't really exist in the module but why this is done when the module and its factory are already defined and they really exist?

This is probably not a test of the service itself, but rather a test of a component **using** that service. And the service is stubbed to return well-known, fake data. That said, the same could be achieved by simply spying on the real service. — JB Nizet, Apr 09 '16 at 08:13
Do you confirm that it's not necessery to redefine the whole factory and its methods when they are already defined ? — Bardelman, Apr 09 '16 at 08:16
This code is posted completely out of context. So I can only guess why the author did that. If it is to test the service itself, it doesn't make much sense to me. If it is to test a component depending on the service, it can make sense, but I usually use a spy instead to do that. But without any context, I might be missing an important piece of the puzzle. — JB Nizet, Apr 09 '16 at 08:19
OK, to just spy is already a suffisant solution and now i suppose the shown techniques in my question's code are just useful for mocking a non existing components. — Bardelman, Apr 09 '16 at 08:21
i have found another good example for the case when it's needed to rewrite an already existing factory by mocking it (or stubbing, i still don't know much the difference) : http://thejsguy.com/2015/01/28/mocking-services-in-angular-with-$provide.html — Bardelman, Apr 09 '16 at 08:43

score 0 · Answer 1 · answered Apr 09 '16 at 13:10

One of the reasons to mock a service is to prevent undesirable actions that would require fixtures (non-$http XHR requests, DOM operations) or have too much moving parts.

Another good reason is to prevent test cross-contamination. If unit A breaks, the developer may want to know what exactly is broken. It becomes harder if B and C unit tests are also red, so the one should follow the breadcrumb to figure out if the troublemaker is A. It becomes much harder if the breadcrumb stops and the one ends up debugging both app and specs instead of fix-and-go type of work.

Unless the test has for an object to test several units together (which is integration test, it complements unit tests and do not replaces them), test each unit in isolation.

Why angular module's factory method should be redefined in the test mock

1 Answers1