In this lecture, we are going to create the components.
At the moment, the component has been registered with a module, but an instance is not available.
Without an instance, we can't test our components, so let's create one.
Specifically, we are going to create a component fixture.
A component fixture is a wrapper around a component instance.
This wrapper gives us additional properties and methods for accessing the components.
These properties will be helpful for testing.
In the resource section of this lecture, I provide a link to the component fixture class.
By using a fixture, it will be easier to access the properties and elements of a component.
Let's give it a try in your editor, open the about test file.
From the testing package.
Import a class called component fixture.
Next at the top of the described block, create a variable called fixture.
This variable will be annotated with the component fixture class.
You may be wondering why are we defining this variable in the described block?
This test file will contain tests related to the about components.
If we have multiple tests, they'll need access to the same component.
It makes sense to define a variable outside of the test by doing so.
All tests will have access to the component.
Next, let's add a generic.
The generic will be the about component.
For type safety, adding a generic is required.
This generic will help Angular understand the type of component we're testing.
After defining the variable, let's create an instance you may have noticed, but we're not assigning
a value to the variable.
The reason is simple.
Each test should always have a unique instance of the component.
This concept is crucial to understand if every test shared the same copy of a component.
Testing would become harder.
It's likely that each test will manipulate the current state of a component.
A shared instance will mean tracking changes across tests.
This can make testing tedious.
What if you need to add or remove tests?
You may need to revisit tests in the future.
Overall, sharing an instance brings up a lot of problems.
To avoid this scenario, it's recommended to create a unique instance for each test by doing so.
Each test does not have to worry about unexpected behavior.
We can use the for each function to create a new instance for each test after the first.
Before each function.
Adding new.
Before each function.
Pass in an arrow function.
Set the fixture variable to the following value test bed dot create component about components.
The create component function will create a new instance of a component.
It has one argument which is the component class.
Awesome.
We've successfully created a new instance of a component for each test.
Before a test runs, we can safely assume that the fixture variable will be reset.
We're not done yet.
Fixtures contain a few properties.
In most cases, you likely won't need access to every property.
It's common to access the component instance.
Developers prefer to store the instance in another variable for readability.
This step is optional, but recommended at the top of the described block.
Create a variable called Component Annotated with the about component class.
Back in the seconds before each function assign the component variable to the fixture dot component
instance property.
The component instance property contains the actual instance of the components.
We'll be able to access the properties and methods of our components class through this property.
You can refer to the documentation for the various properties on the fixture.
After setting this variable run a function called fixture not detect changes.
As we've learned, Angular has a feature called Change Detection for synchronizing a component's properties
with the templates by defaults.
This process is automated for us, however, for testing behavior is different.
Angular will not perform change detection for a component during initialization.
It delays this process.
But why?
You may need to test a component before change detection.
It's uncommon, but it can happen.
For this course, we are not going to cover these types of scenarios.
The testing library gives us the power to manually trigger change detection for a component.
We can do so by running the detect changes function.
Our components, properties and template will be synchronized.
It's time to write a test below the.
Before each function run the ID function with the following description should create.
Next pass in an arrow function as the second argument.
Lastly, write the following code.
Expect component dot to be truthful.
We can verify a component has been created by checking for a true value.
Typically, checking the component has been created is the first test you'll write.
Unlike a sanity test, you will write this test for every class.
Sanity tests only need to be run once.
Let's verify our work by checking out the browser.
The tests should have been picked up by the tool.
As you can see, our test has passed.
We can safely assume the component has been created.
Great.
In the next lecture, let's continue exploring the testing package.