In this lecture, we are going to talk about mocking one aspect of unit testing is isolating a component.
Ideally, the more isolated a component, the better the test.
However, isolating a component is easier said than done.
Components may require dependencies.
For example, the tabs container component had a dependency on the tab component.
Therefore we had to register two components with our testing module.
This situation is not uncommon.
You can't proceed with your tests until all dependencies have been resolved.
However, what if our dependencies have other dependencies the problem can easily compound.
Thus testing can quickly become a nightmare.
For this reason, there's a concept called mocking.
Mocking is the process of creating a fake dependency.
By faking and dependency, our components can behave normally.
Faking a dependency will allow us to isolate the component and worry about one less thing during a test.
The question becomes When should we mock a dependency?
Like I said before, unit testing should focus on a single class or component.
If a dependency is not necessary for a test, we should mock it.
We're going to write one final unit test in my editor.
I'm viewing the navigation component template file.
You should open this file in your editor to the navigation component.
We'll display links in the header before it renders links.
It'll check for the user's authentication status in the template.
Let's scroll to the primary navigation on the first list item element.
We're conditionally rendering this link.
The condition is an observable called is authenticated.
This observable image, the user's authentication status.
If they're not logged in, this link will get rendered.
Otherwise the links in the template element will be rendered.
Our test will force the user to be logged in.
The components template should respond accordingly.
The links from the IMG template element should be available.
We're going to perform a query for these links.
Specifically, we're going to query the logout link.
After selecting this element, we will click the link.
If we're able to perform these actions, we can consider our test a success.
Let's get started.
First, we must rename the test file in the same directory as the template.
Rename the navigation test file by removing the broken extension.
After renaming the file, the server should pick up on our test file.
Let's head over to the browser to check out the results.
The test for creating a component has failed.
Let's read the error message together.
No provider for injection token angular fire error component relies on the authentication service for
checking the user's authentication status.
This service relies on the angular fire package to send a request to our back end.
In a sense, our dependency has another dependency.
Our service will not work without this package being rendered with the testing module.
However, we don't care about our back end.
We don't even care about the authentication service.
The goal of our test is to check that the template renders a set of links for logging users as long
as the service emits a true value.
The service has done its job.
In my opinion.
Rather than configuring Firebase for our tests, we should mock the service.
It'll be easier, faster and more reliable.
Head back to the editor.
Jazmin has a function for creating mocks inside the described function.
Create a variable called mocked off service.
The value for this variable will be the jasmine dot create spi object function.
The Create SPI object function will create an object.
The question is why are we using this function instead of creating a regular object?
Unlike a regular object, Jasmin will spy on the methods of this object.
The idea of spying is simple.
A spy will count the number of times the method has been called.
But why would we need this information?
The logout link from the template should call the logout method from the authentication service, otherwise
the user will not be logged out.
Our test should verify that our component calls the correct method for logging user out of the application.
Without a spy, we can't verify this behavior.
If that doesn't make sense, that's perfectly fine.
You'll see a code example in a moment.
This function has three arguments.
The first argument is the name of the object to mock.
In our case, the dependency is the authentication service class.
The second argument is an array of methods.
Our service has two methods called create user and log outs.
As you can see, we don't have to create the complete logic for our marked service.
The Create SPI object function will handle the implementation details.
The last argument is an object of properties.
Our service has a few properties, however, most of them aren't relevant.
The most important property is the is authenticated dollar sign property.
This is the most important property from our service.
It's an observable that will emit the user's authentication status as a boolean.
Rather than using Firebase to create this observable, let's create an observable that will always emit
true at the top of the file.
Import the of operator from the JS package.
Back in the mock object set the is authenticated property to the of operator in this operator pass in
true.
Mocking the service will give us complete control over the observable.
Rather than waiting for the service to send a request, we can change the observable to always emit
true.
By doing so, we're forcing the user to be logged in creating a mocked service.
It's faster than connecting to Firebase and importing the dependencies.
Our mark is ready in the next lecture.
Let's inject this service into our module.