Then inject it inside a test by calling TestBed.get() with the service class as the argument. it('should use ValueService', () => { service = TestBed.get(ValueService); expect(service.getValue()).toBe('real value'); });

However, you almost always inject service into application classes using Angular dependency injection and you should have tests that reflect that usage pattern. Angular testing utilities make it easy to investigate how injected services behave.

We can even remove the AuthService import if we want, there really is no dependency on anything else. The LoginComponent is tested in isolation:

That’s not very isolated but also not too much to ask for in this scenario. However imagine if LoginComponent required a number of other dependencies in order to run, we would need to know the inner workings of a number of other classes just to test our LoginComponent. This results in Tight Coupling and our tests being very Brittle, i.e. likely to break easily. For example if the AuthService changed how it stored the token, from localStorage to cookies then the LoginComponent test would break since it would still be setting the token via localStorage.

Mocking localStorage is optional, but without mocking getComputedStyle your test won’t run, as Angular checks in which browser it executes. We need to fake it.

Or inside the beforeEach() if you prefer to inject the service as part of your setup. beforeEach(() => { TestBed.configureTestingModule({ providers: [ValueService] }); service = TestBed.get(ValueService); });

Then it gets the native element of the compiled HTML (the HTML rendered by the component).

We use an async before each. The purpose of the async is to let all the possible asynchronous code to finish before continuing.

The CLI takes care of Jasmine and karma configuration for you.