1
00:00:02,939 --> 00:00:07,179
Let me briefly talk to you about angular testing.

2
00:00:07,179 --> 00:00:11,125
How do you design your angular applications to be testable?

3
00:00:11,125 --> 00:00:14,032
How do you design the tests for your angular application?

4
00:00:14,032 --> 00:00:16,359
How do you execute the tests and make sure that

5
00:00:16,359 --> 00:00:20,607
your angular application is satisfying all the tests that you've

6
00:00:20,607 --> 00:00:25,210
written even as you're developing your angular application?

7
00:00:25,210 --> 00:00:27,394
Now this is where I would also briefly talk about

8
00:00:27,394 --> 00:00:31,209
test driven development of angular applications.

9
00:00:31,209 --> 00:00:37,225
Interestingly, angular itself has been built from ground-up to enable testing,

10
00:00:37,225 --> 00:00:40,820
to be part of your angular application development.

11
00:00:40,820 --> 00:00:47,844
The main force behind angular Misko Hevery was himself a Google test engineer and hence,

12
00:00:47,844 --> 00:00:51,850
his influence on designing angular to be testable from

13
00:00:51,850 --> 00:00:56,479
ground-up can easily be seen all over the framework.

14
00:00:56,479 --> 00:01:04,435
So, angular itself as you have understood from the previous lectures and exercises,

15
00:01:04,435 --> 00:01:07,224
is modular in nature.

16
00:01:07,224 --> 00:01:11,155
So the modules of angular together with the components and

17
00:01:11,155 --> 00:01:17,409
their templates and then the services and the pipes and the directives,

18
00:01:17,409 --> 00:01:23,559
mean that angular lends itself easily for being tested.

19
00:01:23,559 --> 00:01:29,049
Now, because the angular application itself is composed of these various parts,

20
00:01:29,049 --> 00:01:32,319
you can test each of those parts in isolation first

21
00:01:32,319 --> 00:01:36,719
even before they become part of the entire angular application.

22
00:01:36,719 --> 00:01:40,820
The second aspect is the dependency injection mechanism that angular leverages

23
00:01:40,820 --> 00:01:45,969
for supporting the combination of the various parts of

24
00:01:45,969 --> 00:01:52,120
your angular application itself means that you can easily substitute mocks

25
00:01:52,120 --> 00:01:54,340
for those dependencies within

26
00:01:54,340 --> 00:01:59,165
your various parts of the angular application and carry out tests.

27
00:01:59,165 --> 00:02:01,135
I have used the word mock in,

28
00:02:01,135 --> 00:02:05,409
in the previous sentence will come to understand

29
00:02:05,409 --> 00:02:10,194
that in a bit more detail and more that, later slides.

30
00:02:10,194 --> 00:02:14,439
This is where we need to be aware of

31
00:02:14,439 --> 00:02:19,724
an approach for doing application development called test-driven development.

32
00:02:19,724 --> 00:02:26,155
In test-driven development, as you can understand by the name itself,

33
00:02:26,155 --> 00:02:29,229
means that you first write automated tests for

34
00:02:29,229 --> 00:02:33,389
all the functionality that you desire to implement within your application.

35
00:02:33,389 --> 00:02:35,004
So first comes the test,

36
00:02:35,004 --> 00:02:39,180
thereafter you write your application code in order to pass the test.

37
00:02:39,180 --> 00:02:44,634
So the test itself specifies what functionality you want to implement.

38
00:02:44,634 --> 00:02:47,840
Thereafter you write the code to implement that functionality.

39
00:02:47,840 --> 00:02:50,165
Since you already have the test in place,

40
00:02:50,165 --> 00:02:58,150
you can test to see whether the implementation that you do satisfies the test or not.

41
00:02:58,150 --> 00:03:04,735
Now, of course, once your realization of your functionality satisfies the test,

42
00:03:04,735 --> 00:03:10,919
you can always refactor the code to comply with their software engineering standards.

43
00:03:10,919 --> 00:03:12,939
But even after that,

44
00:03:12,939 --> 00:03:16,900
you can retest the code to make sure that it still satisfies

45
00:03:16,900 --> 00:03:20,844
those requirements specified within

46
00:03:20,844 --> 00:03:25,914
that specific test that you use within your test-driven development.

47
00:03:25,914 --> 00:03:28,659
So indeed, test-driven development is

48
00:03:28,659 --> 00:03:32,199
a very viable approach for designing

49
00:03:32,199 --> 00:03:36,522
good application from the ground-up to be fully tested.

50
00:03:36,522 --> 00:03:38,340
Now when we talk about testing,

51
00:03:38,340 --> 00:03:42,009
you can approach testing from several different aspects.

52
00:03:42,009 --> 00:03:44,889
The first and foremost is that if your application

53
00:03:44,889 --> 00:03:48,534
itself is implemented as various pieces,

54
00:03:48,534 --> 00:03:52,620
like components, like services, like directives,

55
00:03:52,620 --> 00:03:57,760
like the pipes that you are implementing within your application.

56
00:03:57,760 --> 00:04:03,120
That means that you can easily test each of these individual units in isolation.

57
00:04:03,120 --> 00:04:06,435
So that is where unit tests come to the fore.

58
00:04:06,435 --> 00:04:10,675
Unit test means that you're testing the individual units of code,

59
00:04:10,675 --> 00:04:13,750
making sure that that particular individual unit

60
00:04:13,750 --> 00:04:18,759
satisfies the functionality that it is supposed to support,

61
00:04:18,759 --> 00:04:25,855
and that functionality and the logic within that piece of code is implemented correctly.

62
00:04:25,855 --> 00:04:28,870
Now isolating the unit and testing it is very,

63
00:04:28,870 --> 00:04:35,401
very useful to figure out most of the initial problems within your,

64
00:04:35,401 --> 00:04:41,079
within your code and then fix them even before you integrate that patch into the code.

65
00:04:41,079 --> 00:04:44,259
Now once you start integrating these parts into the whole,

66
00:04:44,259 --> 00:04:50,860
it becomes even more cumbersome to be able to carry out detailed tests of your code.

67
00:04:50,860 --> 00:04:55,839
So, hence, isolated unit tests form the first line

68
00:04:55,839 --> 00:05:01,029
of defense against bugs when you are developing your application,

69
00:05:01,029 --> 00:05:03,904
specifically your angular application.

70
00:05:03,904 --> 00:05:06,189
Now as we see with an angular,

71
00:05:06,189 --> 00:05:10,540
we have a clear separation between the angular components and the DOM itself.

72
00:05:10,540 --> 00:05:13,339
So within a component, for example, there,

73
00:05:13,339 --> 00:05:16,930
the logic of your component is implemented completely in

74
00:05:16,930 --> 00:05:22,101
the typescript code that you implemented within a component that typescript files.

75
00:05:22,101 --> 00:05:25,675
And then the DOM itself is controlled through

76
00:05:25,675 --> 00:05:29,660
the template that you have designed for your angular component.

77
00:05:29,660 --> 00:05:33,475
So Beta itself, you see the clear separation between the two.

78
00:05:33,475 --> 00:05:36,139
So you could simply test just the logic of

79
00:05:36,139 --> 00:05:41,615
your component code itself without writing a vertical template.

80
00:05:41,615 --> 00:05:47,350
But then you could also consider the two together and then evaluate those aspects.

81
00:05:47,350 --> 00:05:50,731
As we will see in the exercise that follows this lecture,

82
00:05:50,731 --> 00:05:53,879
we will actually do both of these approaches.

83
00:05:53,879 --> 00:05:56,685
Not only that, the fact that angular uses

84
00:05:56,685 --> 00:06:01,910
dependency injection means that you can inject mock dependencies within your application.

85
00:06:01,910 --> 00:06:04,279
When I say mock, I mean, for example,

86
00:06:04,279 --> 00:06:08,500
if your component does dependent on a particular service you can always implement

87
00:06:08,500 --> 00:06:13,220
a mock service that mimics the behavior of the service

88
00:06:13,220 --> 00:06:17,689
and then substitute into place while you're testing the component so that you can keep

89
00:06:17,689 --> 00:06:22,550
your component independent of how the service is actually implemented.

90
00:06:22,550 --> 00:06:27,110
As long as the interface between your component and the service is properly designed

91
00:06:27,110 --> 00:06:32,045
you can substitute a mock service in place and still test your component.

92
00:06:32,045 --> 00:06:33,784
There, from the mock,

93
00:06:33,784 --> 00:06:39,470
you can easily control what is supplied to the component from the service.

94
00:06:39,470 --> 00:06:43,220
So this approach enables you to do unit testing

95
00:06:43,220 --> 00:06:47,990
in great detail within your angular application.

96
00:06:47,990 --> 00:06:53,375
This is where the availability of testing frameworks like "Jasmine".

97
00:06:53,375 --> 00:06:55,459
So what Jasmine provides is

98
00:06:55,459 --> 00:07:03,110
a behavior driven testing framework that is completely designed in JavaScript.

99
00:07:03,110 --> 00:07:06,170
Now, this Jasmine framework is a general framework that

100
00:07:06,170 --> 00:07:09,505
is available for testing any JavaScript applications.

101
00:07:09,505 --> 00:07:18,565
Angular adopts Jasmine as the approach for specifying our tests for other angular parts,

102
00:07:18,565 --> 00:07:23,657
their components, the services and various aspects of our angular application.

103
00:07:23,657 --> 00:07:30,730
Now, within Jasmine, Jasmine uses two things that comes to your aid.

104
00:07:30,730 --> 00:07:33,722
One is the use of a "describe" function.

105
00:07:33,722 --> 00:07:38,779
The "describe" function enables you to group a set of tests and then

106
00:07:38,779 --> 00:07:45,110
execute these tests together as a single group of tests.

107
00:07:45,110 --> 00:07:47,884
When we write the code in the exercise you will see me

108
00:07:47,884 --> 00:07:52,225
enclosing a set of tests inside a describe function.

109
00:07:52,225 --> 00:07:55,389
Then we write our code for our,

110
00:07:55,389 --> 00:08:00,214
the Jasmine code, for our angular tests.

111
00:08:00,214 --> 00:08:05,171
Now within these "describe" functions you'll also use what is called as "it" functions.

112
00:08:05,171 --> 00:08:07,550
The "it" functions enable you to specify

113
00:08:07,550 --> 00:08:11,949
individual tests that you want to carry out on your angular application.

114
00:08:11,949 --> 00:08:17,509
So that is where you will see me specifying "it" and then specify that

115
00:08:17,509 --> 00:08:21,185
the nature of the particular test and then

116
00:08:21,185 --> 00:08:25,259
design the code for that particular test with an in "it" function.

117
00:08:25,259 --> 00:08:29,240
So as we design the code in the exercise look out for the "describe" and

118
00:08:29,240 --> 00:08:33,575
the "it" within your angular test applications.

119
00:08:33,575 --> 00:08:37,559
Once you've designed the test with the Jasmine framework,

120
00:08:37,559 --> 00:08:41,600
Karma is a JavaScript based command line tool

121
00:08:41,600 --> 00:08:46,174
that enables you to carry out these tests automatically.

122
00:08:46,174 --> 00:08:48,440
Now, Karma together with Jasmine,

123
00:08:48,440 --> 00:08:53,500
enables you to carry out tests for your angular application.

124
00:08:53,500 --> 00:08:56,375
Now with Karma, what Karma supports,

125
00:08:56,375 --> 00:08:59,065
is that it enables you to spawn

126
00:08:59,065 --> 00:09:04,409
a web server within which you load your application source code and

127
00:09:04,409 --> 00:09:13,370
then Karma then uses a browser to carry out the actual tests of your various units.

128
00:09:13,370 --> 00:09:17,100
So this is where when you run your tests using Karma,

129
00:09:17,100 --> 00:09:19,774
you will see Karma stacking up a browser,

130
00:09:19,774 --> 00:09:26,120
whether it is a browser window of an existing browser or

131
00:09:26,120 --> 00:09:29,174
whether you would use something called PhantomJS which starts

132
00:09:29,174 --> 00:09:32,715
a phantom browser behind the scenes to carry out the test.

133
00:09:32,715 --> 00:09:35,855
It doesn't matter, but Karma uses

134
00:09:35,855 --> 00:09:40,554
the browser in one moment to carry out the test for your angular application.

135
00:09:40,554 --> 00:09:43,356
As you will see in the exercise that follows,

136
00:09:43,356 --> 00:09:50,649
this is where if one of your colleagues keeps insisting that his or her implementation of

137
00:09:50,649 --> 00:09:55,070
a particular piece of your angular application is

138
00:09:55,070 --> 00:09:59,659
correct and keeps emphasizing the point,

139
00:09:59,659 --> 00:10:03,110
you can always design a few tests using Jasmine and

140
00:10:03,110 --> 00:10:07,081
Karma and then carry out the tests and should the tests fail,

141
00:10:07,081 --> 00:10:11,095
you can always disprove their argument.

142
00:10:11,095 --> 00:10:12,615
So that is when you can turn,

143
00:10:12,615 --> 00:10:14,465
turn around to your colleague and say,

144
00:10:14,465 --> 00:10:17,240
my Karma ran over your dogma.

145
00:10:17,240 --> 00:10:21,664
Now, of course, your angular applications are not completely devoid

146
00:10:21,664 --> 00:10:26,419
of the involvement of the angular framework itself.

147
00:10:26,419 --> 00:10:29,210
Your component cannot be designed by yourself without

148
00:10:29,210 --> 00:10:33,850
using many of the library functionality that angular provides for you,

149
00:10:33,850 --> 00:10:39,215
although some of the basic logic can be tested independent of angular.

150
00:10:39,215 --> 00:10:42,125
What we call as isolated tests.

151
00:10:42,125 --> 00:10:44,450
But, more and more,

152
00:10:44,450 --> 00:10:46,659
you will find that unless you in,

153
00:10:46,659 --> 00:10:49,490
want the angular frame support itself you

154
00:10:49,490 --> 00:10:52,565
will not be able to carry out much of the test of

155
00:10:52,565 --> 00:11:00,639
your angular parts whether it is components or services or pipes or directives.

156
00:11:00,639 --> 00:11:05,524
So this is where the angular testing utilities provide

157
00:11:05,524 --> 00:11:08,690
a test environment that enables you to carry

158
00:11:08,690 --> 00:11:12,384
out the unit tests within your angular application.

159
00:11:12,384 --> 00:11:18,139
So the angular testing utilities as you will see me using in the exercises,

160
00:11:18,139 --> 00:11:20,480
in the very next exercise,

161
00:11:20,480 --> 00:11:27,034
will provide us with certain implementations of angular functionality that you use

162
00:11:27,034 --> 00:11:33,950
within your tests in order to set up the environment where you can carry out their tests.

163
00:11:33,950 --> 00:11:37,319
So, this is where the interaction with the angular environment,

164
00:11:37,319 --> 00:11:41,404
instead of using the real angular implementations,

165
00:11:41,404 --> 00:11:45,740
you will use this test utilities that will provide

166
00:11:45,740 --> 00:11:50,355
sufficient functionality to enable you to carry out the tests.

167
00:11:50,355 --> 00:11:53,840
And this is where the TestBed that we will

168
00:11:53,840 --> 00:11:57,825
use within our angular application is very, very useful.

169
00:11:57,825 --> 00:12:02,899
The TestBed essentially creates an angular testing modular.

170
00:12:02,899 --> 00:12:06,205
As you realize, your components don't exist by themselves.

171
00:12:06,205 --> 00:12:09,850
Your components have to be included inside an NG module.

172
00:12:09,850 --> 00:12:14,264
Now you can't simply use a standard NG module for carrying out your testing.

173
00:12:14,264 --> 00:12:16,084
So that is where the TestBed,

174
00:12:16,084 --> 00:12:18,560
that is supported by angular test utility,

175
00:12:18,560 --> 00:12:24,549
provides you with an NG module environment that enables you to test their components.

176
00:12:24,549 --> 00:12:25,850
So, within the TestBed,

177
00:12:25,850 --> 00:12:29,929
you will use something called TestBed Create Component to create

178
00:12:29,929 --> 00:12:36,139
an individual component and an instance of the component to carry out the tests on that.

179
00:12:36,139 --> 00:12:37,940
And when you do that

180
00:12:37,940 --> 00:12:42,454
the TestBed gives you access to something called the ComponentFixture,

181
00:12:42,454 --> 00:12:48,500
the ComponentFixture is something that provides you a handle that enables you to surround

182
00:12:48,500 --> 00:12:56,419
your component with enough functionality such that the component can be tested by itself.

183
00:12:56,419 --> 00:13:00,950
The fixture provides access to the component itself and

184
00:13:00,950 --> 00:13:05,299
then also through that we will use something called the DebugElement.

185
00:13:05,299 --> 00:13:08,375
You will see me using that in the exercise that follows.

186
00:13:08,375 --> 00:13:11,424
The DebugElement gives you access to the DOM,

187
00:13:11,424 --> 00:13:16,754
that is the the template that is supported as part of your component.

188
00:13:16,754 --> 00:13:23,899
So thereby, you can do manipulations on the DOM like clicking of elements in the DOM,

189
00:13:23,899 --> 00:13:29,315
getting access to a DOM element and then reading out what is enclosed

190
00:13:29,315 --> 00:13:35,600
inside those Dom elements and so on which will enable you to carry out the tests.

191
00:13:35,600 --> 00:13:37,669
Now, before we go on to the exercise,

192
00:13:37,669 --> 00:13:43,250
I want you to be aware of some of these things so that when we encounter them in

193
00:13:43,250 --> 00:13:51,139
the exercise itself you will see why I am making use of each of these different pieces.