1
00:00:02,939 --> 00:00:07,179
Позвольте мне кратко поговорить с вами об угловом тестировании.

2
00:00:07,179 --> 00:00:11,125
Как вы разрабатываете свои угловые приложения для тестирования?

3
00:00:11,125 --> 00:00:14,032
Как вы разрабатываете тесты для вашего углового применения?

4
00:00:14,032 --> 00:00:16,359
Как вы выполняете тесты и убедитесь, что

5
00:00:16,359 --> 00:00:20,607
ваше угловое приложение удовлетворяет всем тестам, которые вы написали

6
00:00:20,607 --> 00:00:25,210
, даже когда вы разрабатываете свое угловое приложение?

7
00:00:25,210 --> 00:00:27,394
Теперь здесь я бы также кратко рассказал о

8
00:00:27,394 --> 00:00:31,209
тестовой разработке угловых приложений.

9
00:00:31,209 --> 00:00:37,225
Интересно, что угловой сам был построен с самого основания, чтобы позволить тестирование,

10
00:00:37,225 --> 00:00:40,820
быть частью вашей разработки углового приложения.

11
00:00:40,820 --> 00:00:47,844
Основной силой углового Misko Хевери был сам инженер по тестированию Google и, следовательно,

12
00:00:47,844 --> 00:00:51,850
его влияние на проектирование угловых, чтобы быть проверяемым с

13
00:00:51,850 --> 00:00:56,479
заземления можно легко увидеть по всему каркасу.

14
00:00:56,479 --> 00:01:04,435
Итак, угловой сам по себе, как вы поняли из предыдущих лекций и упражнений,

15
00:01:04,435 --> 00:01:07,224
является модульным по своему характеру.

16
00:01:07,224 --> 00:01:11,155
Таким образом, модули угловых вместе с компонентами и

17
00:01:11,155 --> 00:01:17,409
их шаблоны, а затем услуги и трубы и директивы

18
00:01:17,409 --> 00:01:23,559
означают, что угловой легко поддается испытанию.

19
00:01:23,559 --> 00:01:29,049
Теперь, поскольку угловое приложение само состоит из этих различных частей,

20
00:01:29,049 --> 00:01:32,319
вы можете сначала протестировать каждую из этих частей изолированно

21
00:01:32,319 --> 00:01:36,719
даже до того, как они станут частью всего углового приложения.

22
00:01:36,719 --> 00:01:40,820
Второй аспект - это механизм инъекции зависимостей, который угловой использует

23
00:01:40,820 --> 00:01:45,969
для поддержки комбинации различных частей

24
00:01:45,969 --> 00:01:52,120
ваше угловое приложение само означает, что вы можете легко заменить mocks

25
00:01:52,120 --> 00:01:54,340
для этих зависимостей в пределах

26
00:01:54,340 --> 00:01:59,165
ваших различных частей углового и проводить испытания.

27
00:01:59,165 --> 00:02:01,135
Я использовал слово mock в,

28
00:02:01,135 --> 00:02:05,409
в предыдущем предложении придет понять

29
00:02:05,409 --> 00:02:10,194
, что в немного более подробно и более, что, позже слайды.

30
00:02:10,194 --> 00:02:14,439
Именно здесь мы должны знать

31
00:02:14,439 --> 00:02:19,724
подход к разработке приложений, называемый тестовым развитием.

32
00:02:19,724 --> 00:02:26,155
В тестируемой разработке, как вы можете понять по собственному имени,

33
00:02:26,155 --> 00:02:29,229
означает, что вы сначала пишете автоматизированные тесты для

34
00:02:29,229 --> 00:02:33,389
все функции, которые вы хотите реализовать в своем приложении.

35
00:02:33,389 --> 00:02:35,004
Итак, сначала приходит тест,

36
00:02:35,004 --> 00:02:39,180
после этого вы пишете код приложения, чтобы пройти тест.

37
00:02:39,180 --> 00:02:44,634
Таким образом, сам тест определяет, какую функциональность вы хотите реализовать.

38
00:02:44,634 --> 00:02:47,840
После этого вы пишете код для реализации этой функции.

39
00:02:47,840 --> 00:02:50,165
Поскольку у вас уже есть тест на месте,

40
00:02:50,165 --> 00:02:58,150
вы можете проверить, удовлетворяет ли реализация, которую вы делаете, тест или нет.

41
00:02:58,150 --> 00:03:04,735
Теперь, конечно, как только ваша реализация вашей функциональности удовлетворяет тест,

42
00:03:04,735 --> 00:03:10,919
вы всегда можете реорганизовать код в соответствии с их стандартами разработки программного обеспечения.

43
00:03:10,919 --> 00:03:12,939
Но даже после этого

44
00:03:12,939 --> 00:03:16,900
вы можете повторно проверить код, чтобы убедиться, что он по-прежнему удовлетворяет

45
00:03:16,900 --> 00:03:20,844
требованиям, указанным в

46
00:03:20,844 --> 00:03:25,914
, что конкретный тест, который вы используете в своей тестовой разработке.

47
00:03:25,914 --> 00:03:28,659
Таким образом, разработка на основе тестирования является

48
00:03:28,659 --> 00:03:32,199
очень жизнеспособным подходом к разработке

49
00:03:32,199 --> 00:03:36,522
хорошего приложения с самого основания, чтобы быть полностью протестированы.

50
00:03:36,522 --> 00:03:38,340
Теперь, когда мы говорим о тестировании,

51
00:03:38,340 --> 00:03:42,009
вы можете подойти к тестированию с нескольких различных аспектов.

52
00:03:42,009 --> 00:03:44,889
Прежде всего, что если ваше приложение

53
00:03:44,889 --> 00:03:48,534
само реализовано как различные части,

54
00:03:48,534 --> 00:03:52,620
как компоненты, такие как услуги, как директивы,

55
00:03:52,620 --> 00:03:57,760
, как трубы, которые вы реализуете в своем приложении.

56
00:03:57,760 --> 00:04:03,120
Это означает, что вы можете легко протестировать каждый из этих отдельных блоков изолированно.

57
00:04:03,120 --> 00:04:06,435
Так вот где на первый план выходят модульные тесты.

58
00:04:06,435 --> 00:04:10,675
Unit test означает, что вы тестируете отдельные единицы кода,

59
00:04:10,675 --> 00:04:13,750
убедившись, что этот конкретный единичный блок

60
00:04:13,750 --> 00:04:18,759
удовлетворяет функциям, которые он должен поддерживать,

61
00:04:18,759 --> 00:04:25,855
и что функциональность и логика внутри этого фрагмента кода реализованы правильно.

62
00:04:25,855 --> 00:04:28,870
Теперь изолируя блок и тестируя его очень,

63
00:04:28,870 --> 00:04:35,401
очень полезно выяснить большинство начальных проблем в вашем,

64
00:04:35,401 --> 00:04:41,079
в вашем коде, а затем исправить их даже до того, как вы интегрируете этот патч в код.

65
00:04:41,079 --> 00:04:44,259
Теперь, как только вы начинаете интегрировать эти части в целое,

66
00:04:44,259 --> 00:04:50,860
становится еще более громоздким, чтобы иметь возможность проводить детальные тесты вашего кода.

67
00:04:50,860 --> 00:04:55,839
Таким образом, изолированные модульные тесты образуют первую строку

68
00:04:55,839 --> 00:05:01,029
защиты от ошибок, когда вы разрабатываете свое приложение,

69
00:05:01,029 --> 00:05:03,904
конкретно ваше угловое приложение.

70
00:05:03,904 --> 00:05:06,189
Теперь, как мы видим с угловым,

71
00:05:06,189 --> 00:05:10,540
мы имеем четкое разделение между угловыми компонентами и самим DOM.

72
00:05:10,540 --> 00:05:13,339
Таким образом, внутри компонента, например, есть

73
00:05:13,339 --> 00:05:16,930
логика вашего компонента полностью реализована в

74
00:05:16,930 --> 00:05:22,101
код машинописного кода, который вы реализовали в компоненте, который машинописные файлы.

75
00:05:22,101 --> 00:05:25,675
И тогда сам DOM управляется через

76
00:05:25,675 --> 00:05:29,660
шаблон, который вы разработали для вашего углового компонента.

77
00:05:29,660 --> 00:05:33,475
Итак, Бета сама, вы видите четкое разделение между ними.

78
00:05:33,475 --> 00:05:36,139
Таким образом, вы можете просто проверить только логику

79
00:05:36,139 --> 00:05:41,615
вашего кода компонента без написания вертикального шаблона.

80
00:05:41,615 --> 00:05:47,350
Но тогда вы также могли бы рассмотреть оба вместе, а затем оценить эти аспекты.

81
00:05:47,350 --> 00:05:50,731
Как мы увидим в упражнении, которое следует за этой лекцией,

82
00:05:50,731 --> 00:05:53,879
мы фактически сделаем оба этих подхода.

83
00:05:53,879 --> 00:05:56,685
Мало того, что угловая использует инъекцию зависимостей

84
00:05:56,685 --> 00:06:01,910
, означает, что вы можете вводить макетные зависимости в своем приложении.

85
00:06:01,910 --> 00:06:04,279
Когда я говорю mock, я имею в виду, например,

86
00:06:04,279 --> 00:06:08,500
, если ваш компонент зависит от конкретной службы, вы всегда можете реализовать

87
00:06:08,500 --> 00:06:13,220
макет службы, который имитирует поведение службы

88
00:06:13,220 --> 00:06:17,689
, а затем заменить на место во время тестирования компонента, чтобы вы могли сохранить

89
00:06:17,689 --> 00:06:22,550
ваш компонент независимо от того, как сервис фактически реализован.

90
00:06:22,550 --> 00:06:27,110
До тех пор, пока интерфейс между вашим компонентом и сервисом правильно спроектирован

91
00:06:27,110 --> 00:06:32,045
, вы можете заменить макетный сервис на месте и по-прежнему тестировать свой компонент.

92
00:06:32,045 --> 00:06:33,784
Там, из макета,

93
00:06:33,784 --> 00:06:39,470
вы можете легко контролировать, что поставляется компоненту из сервиса.

94
00:06:39,470 --> 00:06:43,220
Таким образом, этот подход позволяет вам выполнять модульное тестирование

95
00:06:43,220 --> 00:06:47,990
в деталях в вашем угловом приложении.

96
00:06:47,990 --> 00:06:53,375
Вот где доступность тестовых фреймворков типа «Жасмин».

97
00:06:53,375 --> 00:06:55,459
Так что Jasmine предоставляет

98
00:06:55,459 --> 00:07:03,110
управляемая поведением среда тестирования, которая полностью разработана в JavaScript.

99
00:07:03,110 --> 00:07:06,170
Теперь эта структура Jasmine является общей структурой, которая

100
00:07:06,170 --> 00:07:09,505
доступна для тестирования любых приложений JavaScript.

101
00:07:09,505 --> 00:07:18,565
Angular принимает Жасмин в качестве подхода для определения наших испытаний для других угловых деталей,

102
00:07:18,565 --> 00:07:23,657
их компонентов, услуг и различных аспектов нашего углового применения.

103
00:07:23,657 --> 00:07:30,730
Теперь, в Жасмин, Жасмин использует две вещи, которые приходят вам на помощь.

104
00:07:30,730 --> 00:07:33,722
Одним из них является использование функции «описать».

105
00:07:33,722 --> 00:07:38,779
Функция «описать» позволяет сгруппировать набор тестов, а затем

106
00:07:38,779 --> 00:07:45,110
выполнить эти тесты вместе как одну группу тестов.

107
00:07:45,110 --> 00:07:47,884
Когда мы пишем код в упражнении, вы увидите меня

108
00:07:47,884 --> 00:07:52,225
, заключая набор тестов внутри функции описания.

109
00:07:52,225 --> 00:07:55,389
Затем мы пишем наш код для нашего,

110
00:07:55,389 --> 00:08:00,214
код Жасмина, для наших угловых тестов.

111
00:08:00,214 --> 00:08:05,171
Теперь в этих «описать» функциях вы также будете использовать то, что называется «это» функции.

112
00:08:05,171 --> 00:08:07,550
Функции «it» позволяют указать

113
00:08:07,550 --> 00:08:11,949
индивидуальные тесты, которые вы хотите выполнить на вашем угловом приложении.

114
00:08:11,949 --> 00:08:17,509
Так вот где вы увидите, что я указываю «это», а затем укажите, что

115
00:08:17,509 --> 00:08:21,185
характер конкретного теста, а затем

116
00:08:21,185 --> 00:08:25,259
дизайн кода для этого конкретного теста с помощью функции «it».

117
00:08:25,259 --> 00:08:29,240
Так как мы разрабатываем код в упражнении, обратите внимание на «описание» и

118
00:08:29,240 --> 00:08:33,575
«это» в ваших угловых тестовых приложениях.

119
00:08:33,575 --> 00:08:37,559
После того, как вы разработали тест с Jasmine фреймворком,

120
00:08:37,559 --> 00:08:41,600
Karma представляет собой инструмент командной строки на основе JavaScript

121
00:08:41,600 --> 00:08:46,174
, который позволяет выполнять эти тесты автоматически.

122
00:08:46,174 --> 00:08:48,440
Now, Karma вместе с Жасмином,

123
00:08:48,440 --> 00:08:53,500
позволяет вам проводить испытания для вашего углового применения.

124
00:08:53,500 --> 00:08:56,375
Теперь с Karma, что поддерживает Karma,

125
00:08:56,375 --> 00:08:59,065
заключается в том, что он позволяет создавать

126
00:08:59,065 --> 00:09:04,409
веб-сервер, в пределах которого вы загружаете исходный код приложения и

127
00:09:04,409 --> 00:09:13,370
затем Karma использует браузер для проведения фактических тестов ваших различных единиц.

128
00:09:13,370 --> 00:09:17,100
Итак, это где, когда вы запускаете тесты с помощью Karma,

129
00:09:17,100 --> 00:09:19,774
вы увидите, что Karma укладывает браузер,

130
00:09:19,774 --> 00:09:26,120
является ли это окном браузера существующего браузера или

131
00:09:26,120 --> 00:09:29,174
, будете ли вы использовать что-то под названием PhantomJS, которое запускает

132
00:09:29,174 --> 00:09:32,715
фантомный браузер за кулисами для проведения теста.

133
00:09:32,715 --> 00:09:35,855
Это не имеет значения, но Karma использует

134
00:09:35,855 --> 00:09:40,554
браузер в один момент, чтобы провести тест для вашего углового приложения.

135
00:09:40,554 --> 00:09:43,356
Как вы увидите в упражнении, которое следует,

136
00:09:43,356 --> 00:09:50,649
это где, если один из ваших коллег продолжает настаивать на том, что его или ее реализация

137
00:09:50,649 --> 00:09:55,070
конкретный кусок вашего углового приложения является

138
00:09:55,070 --> 00:09:59,659
правильным и продолжает подчеркивать точку,

139
00:09:59,659 --> 00:10:03,110
вы всегда можете разработать несколько тестов, используя Жасмин и

140
00:10:03,110 --> 00:10:07,081
Карма, а затем провести тесты и в случае неудачи тестов,

141
00:10:07,081 --> 00:10:11,095
вы всегда можете опровергнуть их аргумент.

142
00:10:11,095 --> 00:10:12,615
Так вот, когда вы можете повернуться,

143
00:10:12,615 --> 00:10:14,465
обернуться к своему коллеге и сказать:

144
00:10:14,465 --> 00:10:17,240
моя Карма наехала на вашу догму.

145
00:10:17,240 --> 00:10:21,664
Теперь, конечно, ваши угловые приложения не полностью лишенные

146
00:10:21,664 --> 00:10:26,419
вовлеченности самого углового каркаса.

147
00:10:26,419 --> 00:10:29,210
Ваш компонент не может быть спроектирован самостоятельно без

148
00:10:29,210 --> 00:10:33,850
, используя многие функциональные возможности библиотеки, которые угловой обеспечивает для вас,

149
00:10:33,850 --> 00:10:39,215
хотя некоторые из основных логики могут быть протестированы независимо от угловых.

150
00:10:39,215 --> 00:10:42,125
То, что мы называем изолированными тестами.

151
00:10:42,125 --> 00:10:44,450
Но, все больше и больше,

152
00:10:44,450 --> 00:10:46,659
вы обнаружите, что если вы в,

153
00:10:46,659 --> 00:10:49,490
хотите, чтобы угловая рама поддерживает себя вы

154
00:10:49,490 --> 00:10:52,565
не сможете выполнять большую часть теста

155
00:10:52,565 --> 00:11:00,639
ваших угловых частей, будь то компоненты или услуги или трубы или директивы.

156
00:11:00,639 --> 00:11:05,524
Таким образом, здесь утилиты углового тестирования предоставляют

157
00:11:05,524 --> 00:11:08,690
тестовую среду, которая позволяет выполнять

158
00:11:08,690 --> 00:11:12,384
модульные тесты в пределах вашего углового приложения.

159
00:11:12,384 --> 00:11:18,139
Так что угловые утилиты тестирования, как вы увидите меня, используя в упражнениях,

160
00:11:18,139 --> 00:11:20,480
в самом следующем упражнении,

161
00:11:20,480 --> 00:11:27,034
предоставит нам определенные реализации угловой функциональности, которые вы используете

162
00:11:27,034 --> 00:11:33,950
в ваших тестах для того, чтобы настроить среду, где вы можете выполнять их тесты.

163
00:11:33,950 --> 00:11:37,319
Итак, вот где взаимодействие с угловой средой,

164
00:11:37,319 --> 00:11:41,404
вместо использования реальных угловых реализаций,

165
00:11:41,404 --> 00:11:45,740
вы будете использовать эти тестовые утилиты, которые обеспечат

166
00:11:45,740 --> 00:11:50,355
достаточную функциональность, чтобы позволить вам проводить тесты.

167
00:11:50,355 --> 00:11:53,840
И именно здесь TestBed, который мы будем использовать

168
00:11:53,840 --> 00:11:57,825
в нашем угловом приложении, очень полезно.

169
00:11:57,825 --> 00:12:02,899
TestBed по существу создает угловое тестирование модульной.

170
00:12:02,899 --> 00:12:06,205
Как вы понимаете, ваши компоненты не существуют сами по себе.

171
00:12:06,205 --> 00:12:09,850
Ваши компоненты должны быть включены в модуль NG.

172
00:12:09,850 --> 00:12:14,264
Теперь вы не можете просто использовать стандартный модуль NG для проведения тестирования.

173
00:12:14,264 --> 00:12:16,084
Так вот где TestBed,

174
00:12:16,084 --> 00:12:18,560
, который поддерживается утилита углового тестирования,

175
00:12:18,560 --> 00:12:24,549
предоставляет вам среду модуля NG, которая позволяет тестировать их компоненты.

176
00:12:24,549 --> 00:12:25,850
Таким образом, в TestBed,

177
00:12:25,850 --> 00:12:29,929
вы будете использовать что-то под названием TestBed Create Component для создания

178
00:12:29,929 --> 00:12:36,139
отдельного компонента и экземпляра компонента для выполнения тестов на этом.

179
00:12:36,139 --> 00:12:37,940
И когда вы делаете это

180
00:12:37,940 --> 00:12:42,454
TestBed дает вам доступ к что-то под названием ComponentFixture,

181
00:12:42,454 --> 00:12:48,500
ComponentFixture это то, что предоставляет вам ручку, которая позволяет окружить

182
00:12:48,500 --> 00:12:56,419
ваш компонент с достаточной функциональностью, что компонент может быть протестирован сам по себе.

183
00:12:56,419 --> 00:13:00,950
Прибор обеспечивает доступ к самому компоненту и

184
00:13:00,950 --> 00:13:05,299
, то также через это мы будем использовать что-то под названием DebugElement.

185
00:13:05,299 --> 00:13:08,375
Вы увидите, что я использую это в следующем упражнении.

186
00:13:08,375 --> 00:13:11,424
DebugElement предоставляет вам доступ к DOM,

187
00:13:11,424 --> 00:13:16,754
, который является шаблоном, который поддерживается как часть вашего компонента.

188
00:13:16,754 --> 00:13:23,899
Таким образом, вы можете делать манипуляции с DOM, такие как щелчок элементов в DOM,

189
00:13:23,899 --> 00:13:29,315
получение доступа к элементу DOM, а затем чтение того, что заключено

190
00:13:29,315 --> 00:13:35,600
внутри этих элементов Dom и так далее, что позволит вам выполнять тесты.

191
00:13:35,600 --> 00:13:37,669
Теперь, прежде чем мы перейдем к упражнению,

192
00:13:37,669 --> 00:13:43,250
я хочу, чтобы вы знали о некоторых из этих вещей, так что, когда мы столкнемся с ними в

193
00:13:43,250 --> 00:13:51,139
само упражнение, вы увидите, почему я использую каждую из этих различных частей.