1
00:00:00,530 --> 00:00:04,080
In this lecture, we are going to create the components.

2
00:00:04,100 --> 00:00:09,950
At the moment, the component has been registered with a module, but an instance is not available.

3
00:00:09,950 --> 00:00:15,350
Without an instance, we can't test our components, so let's create one.

4
00:00:15,350 --> 00:00:19,700
Specifically, we are going to create a component fixture.

5
00:00:19,730 --> 00:00:24,020
A component fixture is a wrapper around a component instance.

6
00:00:24,020 --> 00:00:29,690
This wrapper gives us additional properties and methods for accessing the components.

7
00:00:29,690 --> 00:00:32,689
These properties will be helpful for testing.

8
00:00:32,900 --> 00:00:39,110
In the resource section of this lecture, I provide a link to the component fixture class.

9
00:00:39,110 --> 00:00:45,140
By using a fixture, it will be easier to access the properties and elements of a component.

10
00:00:45,170 --> 00:00:50,150
Let's give it a try in your editor, open the about test file.

11
00:00:52,390 --> 00:00:54,130
From the testing package.

12
00:00:54,160 --> 00:00:57,190
Import a class called component fixture.

13
00:00:59,520 --> 00:01:04,920
Next at the top of the described block, create a variable called fixture.

14
00:01:04,950 --> 00:01:09,780
This variable will be annotated with the component fixture class.

15
00:01:11,940 --> 00:01:16,440
You may be wondering why are we defining this variable in the described block?

16
00:01:16,470 --> 00:01:21,160
This test file will contain tests related to the about components.

17
00:01:21,180 --> 00:01:25,980
If we have multiple tests, they'll need access to the same component.

18
00:01:26,010 --> 00:01:30,840
It makes sense to define a variable outside of the test by doing so.

19
00:01:30,870 --> 00:01:34,140
All tests will have access to the component.

20
00:01:34,170 --> 00:01:36,390
Next, let's add a generic.

21
00:01:36,420 --> 00:01:39,210
The generic will be the about component.

22
00:01:41,360 --> 00:01:44,940
For type safety, adding a generic is required.

23
00:01:44,960 --> 00:01:50,220
This generic will help Angular understand the type of component we're testing.

24
00:01:50,240 --> 00:01:56,480
After defining the variable, let's create an instance you may have noticed, but we're not assigning

25
00:01:56,480 --> 00:01:58,050
a value to the variable.

26
00:01:58,070 --> 00:01:59,780
The reason is simple.

27
00:01:59,810 --> 00:02:04,520
Each test should always have a unique instance of the component.

28
00:02:04,730 --> 00:02:11,090
This concept is crucial to understand if every test shared the same copy of a component.

29
00:02:11,120 --> 00:02:12,870
Testing would become harder.

30
00:02:12,890 --> 00:02:17,810
It's likely that each test will manipulate the current state of a component.

31
00:02:17,840 --> 00:02:22,070
A shared instance will mean tracking changes across tests.

32
00:02:22,100 --> 00:02:24,180
This can make testing tedious.

33
00:02:24,200 --> 00:02:26,850
What if you need to add or remove tests?

34
00:02:26,870 --> 00:02:29,840
You may need to revisit tests in the future.

35
00:02:29,870 --> 00:02:33,890
Overall, sharing an instance brings up a lot of problems.

36
00:02:33,920 --> 00:02:41,120
To avoid this scenario, it's recommended to create a unique instance for each test by doing so.

37
00:02:41,150 --> 00:02:45,250
Each test does not have to worry about unexpected behavior.

38
00:02:45,260 --> 00:02:52,160
We can use the for each function to create a new instance for each test after the first.

39
00:02:52,160 --> 00:02:53,690
Before each function.

40
00:02:53,690 --> 00:02:54,470
Adding new.

41
00:02:54,470 --> 00:02:56,030
Before each function.

42
00:02:58,260 --> 00:03:00,090
Pass in an arrow function.

43
00:03:02,140 --> 00:03:09,940
Set the fixture variable to the following value test bed dot create component about components.

44
00:03:12,120 --> 00:03:16,840
The create component function will create a new instance of a component.

45
00:03:16,860 --> 00:03:20,070
It has one argument which is the component class.

46
00:03:20,100 --> 00:03:20,790
Awesome.

47
00:03:20,790 --> 00:03:25,770
We've successfully created a new instance of a component for each test.

48
00:03:25,770 --> 00:03:31,980
Before a test runs, we can safely assume that the fixture variable will be reset.

49
00:03:32,010 --> 00:03:33,390
We're not done yet.

50
00:03:33,420 --> 00:03:35,820
Fixtures contain a few properties.

51
00:03:35,820 --> 00:03:40,260
In most cases, you likely won't need access to every property.

52
00:03:40,260 --> 00:03:43,380
It's common to access the component instance.

53
00:03:43,380 --> 00:03:48,350
Developers prefer to store the instance in another variable for readability.

54
00:03:48,360 --> 00:03:53,430
This step is optional, but recommended at the top of the described block.

55
00:03:53,430 --> 00:03:59,640
Create a variable called Component Annotated with the about component class.

56
00:04:01,920 --> 00:04:09,120
Back in the seconds before each function assign the component variable to the fixture dot component

57
00:04:09,120 --> 00:04:10,500
instance property.

58
00:04:12,840 --> 00:04:18,060
The component instance property contains the actual instance of the components.

59
00:04:18,060 --> 00:04:23,920
We'll be able to access the properties and methods of our components class through this property.

60
00:04:23,940 --> 00:04:28,890
You can refer to the documentation for the various properties on the fixture.

61
00:04:28,920 --> 00:04:35,160
After setting this variable run a function called fixture not detect changes.

62
00:04:37,400 --> 00:04:44,210
As we've learned, Angular has a feature called Change Detection for synchronizing a component's properties

63
00:04:44,210 --> 00:04:46,460
with the templates by defaults.

64
00:04:46,490 --> 00:04:52,310
This process is automated for us, however, for testing behavior is different.

65
00:04:52,340 --> 00:04:57,690
Angular will not perform change detection for a component during initialization.

66
00:04:57,710 --> 00:04:59,390
It delays this process.

67
00:04:59,390 --> 00:05:00,290
But why?

68
00:05:00,290 --> 00:05:04,220
You may need to test a component before change detection.

69
00:05:04,250 --> 00:05:06,680
It's uncommon, but it can happen.

70
00:05:06,710 --> 00:05:10,920
For this course, we are not going to cover these types of scenarios.

71
00:05:10,940 --> 00:05:16,790
The testing library gives us the power to manually trigger change detection for a component.

72
00:05:16,790 --> 00:05:20,660
We can do so by running the detect changes function.

73
00:05:20,780 --> 00:05:24,530
Our components, properties and template will be synchronized.

74
00:05:24,560 --> 00:05:27,310
It's time to write a test below the.

75
00:05:27,330 --> 00:05:33,620
Before each function run the ID function with the following description should create.

76
00:05:35,800 --> 00:05:39,730
Next pass in an arrow function as the second argument.

77
00:05:41,790 --> 00:05:44,250
Lastly, write the following code.

78
00:05:44,280 --> 00:05:47,780
Expect component dot to be truthful.

79
00:05:49,950 --> 00:05:54,720
We can verify a component has been created by checking for a true value.

80
00:05:54,750 --> 00:05:59,820
Typically, checking the component has been created is the first test you'll write.

81
00:05:59,850 --> 00:06:04,200
Unlike a sanity test, you will write this test for every class.

82
00:06:04,230 --> 00:06:07,550
Sanity tests only need to be run once.

83
00:06:07,560 --> 00:06:10,950
Let's verify our work by checking out the browser.

84
00:06:13,170 --> 00:06:15,790
The tests should have been picked up by the tool.

85
00:06:15,810 --> 00:06:18,530
As you can see, our test has passed.

86
00:06:18,540 --> 00:06:21,850
We can safely assume the component has been created.

87
00:06:21,870 --> 00:06:22,440
Great.

88
00:06:22,470 --> 00:06:26,640
In the next lecture, let's continue exploring the testing package.