如何在函数内部调用的Karma单元测试中模拟Promise

Question

I have the following function in my Angular controller and want to test, if the promise returns the expected result

    function getName() {
      var name = "";
      nameService.getName().then(function (data) {
        name = data.name;
      });
      return name;
    }

How can I mock the promise call with fake data? I am not sure if I can use $httpBackend or $provide here? I tried this but it didn't work:

it("function getName should get the name from the nameService.getNameInfo function", function () {
        var name = { name: "name1"};
        spyOn(mockNameService, 'getNameInfo').and.callFake(function() {
            return {
                then: function(callback) {return callback(name);}
            };
        });
        var result = myCtrl.getName();
        expect(result).toEqual("name1");
    });

Answer 1

Try using:

spyOn(mockNameService, 'getNameInfo').and.returns($q.when('dummyData'));

to mock your data. Then you need to verify once it is resolved. So write:

expect(myCtrl.getName().then(function(name){
    expect(name).toBe('dummyData');
}).toBeResolved();

Answer 2

The problem is not with your unit testing code, its an wrong implementation at all of the application code. here:

function getName() {
      var name = "";
      nameService.getName().then(function (data) {
        name = data.name;
      });
      return name; //it will return "" because the promise yet not resolved
    }

In this code function getName will always return a empty string "" and it will never return the values you are assigning when the promise resolves name = data.name because promises are asynchronous, so by the time its resolves the function getName already returned the empty string to the caller! So, in this case, refactoring the original code and fixed it there dhould be the first idea!

Actually your unit test codes identified the bug in your code, so its served already its original purpose, test case failing doesn't always meant that you have to fix it there, rather if your test cases are perfectly written against the logical expectation for all possible units/modules you need to think about why it is failing, looking at the actual code, and that is the actual purpose of writing unit test cases