Which is of the type MenuComponent.
Now, why is this interesting?
Now, within our Angular application,
we have the MenuComponent that we have already designed.
So So in this test file,
we're going to create that MenuComponent using the angular TestBed,
and then we're going to carry out the tests on the MenuComponent.
So we're going to isolate the MenuComponent, and
then carry out unit tests on that specific component.
Now, this is where the angular testing utilities
which come with support using TestBed.
The TestBed allows me to set up the environment within which
I can test my angular component.
So here, you see that we are saying TestBed and
then calling the configure testing module method of the TestBed class here.
And inside this configure testing module,
you can declare a bunch of things, and you will see me adding more here.
This acts exactly like the NG module configuration
that you do for our at module there.
So all the information that you need for
setting up the MenuComponent will be declared here.
So the NG model part that you saw in the app module,
similar kind of syntax can be used here to declare the support for
testing the MenuComponent here.
And also after this, you will see this function called to compileComponents.
So this method will compile the MenuComponent and
make it ready for doing the testing.
Note also, that this whole thing, this function here,
is enclosed inside something called an async here.
Now, why do we need this async?
Now, because the preparation of the components using this
compileComponents method takes some amount of time.
And until this is completed, we can't proceed forward with the tests.
So using the async module, we are essentially specifying that
I'm going to wait for this whole thing to complete before proceeding forward.
So the asynch module as you see,
wraps a test function inside an asynchronous test zone.
So, what this means is that this test will automatically complete
when all the asynchronous calls inside this zone are done.
So this is what the use of the async that we have here, does.
So what this means is that you can use this sync function,
either in the before each or in the it also, so within the it, our declaration.
So when you see within the it also, you will see that you can use the async.
So in case you have any operations here that done asynchronously.
Then you need to wait for those operations to complete for that test to complete.
So for example, if you are calling a service and wait for
the service to return the value then.
All that needs to complete before you can proceed forward.
So those are enabled by using this async, to surround this function here.
Now, in addition, the second beforeEach, now we have separated
this into two separate beforeEach here, because we want this to complete.
And this compileComponents is going to take a certain amount of time,
especially if your component is using an external template,
as we do in our MenuComponent.
So, it requires some time for the external template to get ready for
my testing to proceed forward.
So, we need to wait for this whole thing to complete.
So that is why after this is complete,
then we will get to the second part where we are going to
get some references to some values from the test bed.
Now, what is this beforeEach function that you are doing here?
What the beforeEach means is that whatever you declare inside here,
that function will be executed beforeEach test,
that you are going to specify later on using the it.
So using this beforeEach, you can set up the initial
configuration for your test to proceed forward.
So meaning that here, we are setting up our TestBed,
preparing our menu component and then setting up a few things for
our menu component, before we proceed on to carry out the test.
So for each of the test that you're going to specify using an it here,
these before each whatever you specify in this before each,
will be executed before the test is conducted.
So here as you can see I am preparing the TestBed.
Then after, I am getting access to the fixture.
So I am using the TestBed, I'm saying createComponent and MenuComponent.
So this will return me a reference to the MenuComponent that
I'm creating within my test script here and
then get a reference to that, because I will need a reference to
that in order to do some manipulations on that component there.
In addition, from the fixture, I am getting an access to the component
instance that is being created by my component fixture here.
So as you can see, the component fixture of the type MenuComponent and
then calling the componentInstance, gives me access to that specific menu
component that I have created inside the TestBed for carrying out the unit tests.
Now, after this we call this this detectChanges.
Now, what this means is that this will proceed forward only after all the changes
are completed, and then recognize that the changes have completed.
So this will trigger a change detection cycle for this component.
So what this means is that this will ensure that you have made any
changes earlier, all the changes are detected and
everything is stabilized before you can proceed forward with your test.
Now, after this, we're going to use our it to configure our first test here.
What is the first test that we are doing here?
The first test,
what we're going to test is to make sure that the component has been created.
So, within this here, I'm using the Jasmin syntax and I'm saying it.
And then here you can give a description in the form of a string
to specify what this test is actually testing about.
So, what we are saying is,
we are testing to see if the component has been created or not.
So to do that, I'm saying it should create meaning that,
this setup here should have created the component correctly.
So that's why inside here, I'm using this method called expect.
So the expect method inside here takes a value here, and
then you can test to see if this value satisfies something.
So here we are saying toBeTruthy, meaning that this particular value should be true.
That is what is specified by this method called here called toBetruthy.
You can also say toBefalsy, meaning that should evaluate to false.
But in this case,
we are testing to make sure that the component has been created correctly.
So that's why we're saying expect toBetruthy here.
So this is a simple test that we are doing to make sure that our
component is correctly getting created.
But as we realize when I run this test, it is not running correctly.
Let's quickly glance and see what the problem is within
our component creation in the console window there.
Going back to the console window, let me just browse back and
see where the problem is.
And I'm beginning to notice that this is specifying that it doesn't seem
to be recognizing some of the things that my component is using.
In particular, it is saying that the MdSpinach
is something that it doesn't recognize,
the MdGetGridList and a few other things.
That immediately suggests to me that I need to do a few more
configurations within my test file before my test can run correctly.
So, let's go back to our spec file and make some changes to it.
Going back to our spec file,
from our recollection of how we created the template.
We know that within the template we had a router link in the MenuComponent's
template.
So I need support for routing in order to recognize that router
link that we used within the MenuComponent.html file.
So this is where I'm going to import
another test support provided
called as the RouterTestingModule,
which is available from Angular/router/testing library here.
So this router testing module will enable me to
configure some aspects about my router.
We will see that the way we use this is a little different from the router module
that we have used in our application.
So we will import the routing testing module, also you note
that we are using some animations, and
also using the Angular material component within our template.
So I need to import
the BrowserAnimationsModule into my test file.