Trying to understand Jasmine's toHaveBeenCalled() matcher

Looking at your use-case, I can't recommend using toHaveBeenCalled here. toHaveBeenCalled is useful in cases where you want test callbacks (async) or in combination with mocks.

Consider everything that happens within Auth.prototype.Login as implementation detail which is not visible to the "outerworld". You shouldn't test implementation details. Which triggers two questions.

Why shouldn't I test implementation details?

It makes refactoring hard. Let's say you want to replace Auth.prototype.isEmpty for some reasons by underscore.isEmpty. Some days later you decide to replace underscore completely by lodash. This would force you to change your test three times. Consider everything that prevents you from refactoring easily as a "no-go".

What shall I test instead?

Public API. Everything that is visible to the "outerworld". Which is in your case "Logged In !" and "Username or Password cann't be blank ".

Which results in 3 tests:

describe('Login', function() {

 it('returns "success" string when username and password are not empty', function() {
   expect(new Auth().Login('non-empty', 'non-empty')).toBe('Logged In !');
 });

 it('returns "failure" string when username is empty', function() {
   expect(new Auth().Login('', 'non-empty')).toBe('Username or Password cannot be blank');
 });

 it('returns "failure" string when password is empty', function() {
   expect(new Auth().Login('non-empty', '')).toBe('Username or Password cannot be blank');
 });

});

EDIT: Look at basecode answer for a better approach

---

From the docs, you should use it like the following:

spyOn(foo, 'setBar');

it("tracks that the spy was called", function() {
  expect(foo.setBar).toHaveBeenCalled();
});

So you should write:

it("should be able to Login", function () {
  spyOn(authobj, 'isEmpty');  
  authobj.Login('abc', 'abc');  
  expect(authobj.isEmpty).toHaveBeenCalled();
});