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'); });
this is for testing the service, directly
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.
key point
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 a key point - isolating stuff. remember this is unit testing, not integration tests. we wish to have as little as dependencies as possible.
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.
key points - this shows the benefits (easy) of this kind of testing and its disadvantages (coupled, easy to break if a service changes its implementation)
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.
key point
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); });
this corresponds with the option mentioned above - inject it inside a single test
Then it gets the native element of the compiled HTML (the HTML rendered by the component).
This explains what 'native element' is, at least in this case. Its the outcome HTML after the detectChanges()
We use an async before each. The purpose of the async is to let all the possible asynchronous code to finish before continuing.
Is this like putting your code in setTimeout() just to push it into the event loop task queue?...
The CLI takes care of Jasmine and karma configuration for you.
meaning, creating a new app using ng new will create the needed mentioned (below) config files