1
00:00:00,000 --> 00:00:04,307
[МУЗЫКА]

2
00:00:04,307 --> 00:00:09,895
В предыдущей лекции и упражнении, которые последовали за лекцией,

3
00:00:09,895 --> 00:00:14,330
мы рассмотрели использование модульных тестов в Angular.

4
00:00:14,330 --> 00:00:18,920
Мы видели, как различные части нашего углового приложения, компоненты,

5
00:00:18,920 --> 00:00:26,420
услуги, директивы, трубы все могут быть протестированы с помощью модульных тестов.

6
00:00:26,420 --> 00:00:27,000
Но, конечно, модульные тесты

7
00:00:27,000 --> 00:00:32,550
не раскрывают все о взаимодействии между компонентами.

8
00:00:32,550 --> 00:00:37,090
Именно здесь сквозные стратегии тестирования позволяют нам

9
00:00:37,090 --> 00:00:42,480
видеть все приложение, работающее как единое целое.

10
00:00:42,480 --> 00:00:49,200
Итак, в этой лекции мы рассмотрим использование сквозных тестов и

11
00:00:49,200 --> 00:00:54,950
, какую роль они играют в общей стратегии тестирования для наших угловых приложений.

12
00:00:54,950 --> 00:01:01,592
В следующем упражнении мы кратко рассмотрим, как мы можем проводить сквозное тестирование

13
00:01:01,592 --> 00:01:06,160
для нашего углового приложения, используя инструмент под названием Protractor.

14
00:01:08,110 --> 00:01:13,710
Как мы уже узнали в предыдущей лекции, модульные тесты

15
00:01:13,710 --> 00:01:19,650
предоставляют нам прекрасную возможность для тестирования наших устройств изолированно.

16
00:01:19,650 --> 00:01:25,105
Убедившись, что наши подразделения выполняют то, что они должны выполнить,

17
00:01:25,105 --> 00:01:29,446
их логика верна, и взаимодействие между компонентом и

18
00:01:29,446 --> 00:01:33,720
его шаблоном хорошо налажено.

19
00:01:33,720 --> 00:01:38,230
Но, конечно, модульные тесты не

20
00:01:38,230 --> 00:01:43,720
завершают всю картину того, как работает типичное угловое приложение.

21
00:01:43,720 --> 00:01:47,807
У вас нет отдельных подразделений, работающих в изоляции.

22
00:01:47,807 --> 00:01:51,293
Вместо этого ваши компоненты взаимодействуют со службами.

23
00:01:51,293 --> 00:01:53,573
Компоненты могут использовать типы.

24
00:01:53,573 --> 00:01:58,503
Сервисы, в свою очередь, будут взаимодействовать с бэкендом для получения данных.

25
00:01:58,503 --> 00:02:02,300
И тогда сам компонент будет отвечать за рендеринг представлений

26
00:02:02,300 --> 00:02:06,670
с использованием шаблонов для компонента.

27
00:02:06,670 --> 00:02:13,686
Итак, как весь этот набор единиц работает вместе?

28
00:02:13,686 --> 00:02:18,485
И как мы можем гарантировать, что совместная работа этих

29
00:02:18,485 --> 00:02:22,202
полностью свободна от проблем?

30
00:02:22,202 --> 00:02:26,931
Так вот где сквозное тестирование и тестирование интеграции

31
00:02:26,931 --> 00:02:32,780
помогает нам охватить такие сценарии.

32
00:02:32,780 --> 00:02:39,190
Конечно, модульные тесты играют важную роль в общей стратегии тестирования.

33
00:02:39,190 --> 00:02:42,133
Но не выполняя сквозные тесты,

34
00:02:42,133 --> 00:02:47,852
мы не можем быть полностью уверены, что наше приложение работает так, как ожидалось.

35
00:02:47,852 --> 00:02:52,697
Одна вещь, которую я должен подчеркнуть, заключается в том, что модульные тесты быстры и

36
00:02:52,697 --> 00:02:56,790
очень легко повторить и могут быть сделаны несколько раз.

37
00:02:56,790 --> 00:03:01,861
Интеграционные тесты и сквозной тест медленны, и поэтому они используются

38
00:03:01,861 --> 00:03:08,390
только для подтверждения того, что ваше приложение работает должным образом.

39
00:03:08,390 --> 00:03:11,830
Итак, когда мы смотрим на нашу общую стратегию тестирования,

40
00:03:11,830 --> 00:03:16,070
мы можем рассматривать ее как организованную в виде пирамиды.

41
00:03:16,070 --> 00:03:19,940
В нижней части пирамиды, занимающей всю базу и

42
00:03:19,940 --> 00:03:25,251
, образующие основу нашей общей стратегии тестирования, находятся модульные тесты.

43
00:03:26,710 --> 00:03:31,790
Как мы узнали, модульные тесты позволяют нам тестировать отдельные единицы в изоляции,

44
00:03:31,790 --> 00:03:35,460
убедившись, что их логика и

45
00:03:35,460 --> 00:03:39,970
, как эти единицы работают правильно.

46
00:03:39,970 --> 00:03:42,890
И эти тесты можно повторять очень часто.

47
00:03:42,890 --> 00:03:48,040
И действительно, следует повторять часто, чтобы убедиться, что отдельные единицы

48
00:03:48,040 --> 00:03:49,610
работают так, как ожидалось.

49
00:03:50,630 --> 00:03:57,850
Конечно, на втором уровне этой стратегии будут интеграционные тесты.

50
00:03:57,850 --> 00:04:02,600
Как небольшая группа единиц работает вместе в

51
00:04:02,600 --> 00:04:07,680
, реализуя все, что необходимо сделать этой группой единиц?

52
00:04:07,680 --> 00:04:12,460
Так что, возможно, мы могли бы протестировать компонент вместе с

53
00:04:12,460 --> 00:04:17,730
его услугами, чтобы увидеть, как происходит поток информации между ними.

54
00:04:17,730 --> 00:04:22,880
Но в верхней части этой пирамиды заканчивается тесты, где

55
00:04:22,880 --> 00:04:25,320
мы смотрим на общее приложение.

56
00:04:25,320 --> 00:04:29,880
И насколько хорошо работает приложение и

57
00:04:29,880 --> 00:04:32,890
соответствует его ожидаемым требованиям.

58
00:04:32,890 --> 00:04:36,990
Так вот где мы видим использование сквозных тестов.

59
00:04:36,990 --> 00:04:42,680
Как вы уже могли ожидать на этой диаграмме, сквозные тесты медленны.

60
00:04:42,680 --> 00:04:48,584
И поэтому мы не проводим сквозные тесты очень часто, вместо этого,

61
00:04:48,584 --> 00:04:55,412
модульный тест формирует основную стратегию для нашего тестирования нашего углового приложения.

62
00:04:55,412 --> 00:05:02,149
Сквозные тесты вносят свой вклад в общую картину, но они проводятся не так

63
00:05:02,149 --> 00:05:08,021
часто, но все же являются неотъемлемой частью нашей стратегии тестирования.

64
00:05:08,021 --> 00:05:10,852
Итак, как мы проводим окончательные тесты?

65
00:05:10,852 --> 00:05:15,210
Давайте кратко поговорим об инструментах, которые доступны для нас.

66
00:05:15,210 --> 00:05:18,199
Среда углового тестирования для сквозных испытаний

67
00:05:18,199 --> 00:05:23,740
поддерживается инструментом Protractor.

68
00:05:23,740 --> 00:05:27,930
Кто говорит, что у гиков нет чувства юмора?

69
00:05:27,930 --> 00:05:30,950
Транспортир, Угловой, вот вы идете.

70
00:05:30,950 --> 00:05:33,450
Так что же такое «Транспортрактор»?

71
00:05:33,450 --> 00:05:37,500
Protractor - это, как и следовало ожидать, программа узлов.

72
00:05:37,500 --> 00:05:40,940
Таким образом, это позволяет нам проводить сквозные тесты.

73
00:05:40,940 --> 00:05:45,510
Таким образом, Protractor проводит тесты против вашего приложения.

74
00:05:45,510 --> 00:05:49,800
Таким образом, Protractor загружает ваше приложение в браузер и взаимодействует с

75
00:05:49,800 --> 00:05:54,570
приложение так же, как реальный пользователь будет взаимодействовать с вашим приложением.

76
00:05:54,570 --> 00:05:59,160
Таким образом, мы смотрим на взаимодействие с вашим приложением

77
00:05:59,160 --> 00:06:03,410
, хотя программно, но выполнение таких операций, которые

78
00:06:03,410 --> 00:06:07,500
типичный пользователь будет выполнять, как щелчок по ссылкам, заполнение форм.

79
00:06:07,500 --> 00:06:13,110
Отправка форм, переход к различным частям заявки и так далее.

80
00:06:13,110 --> 00:06:18,310
Таким образом, это где Protractor использует использование WebDriver для управления браузерами

81
00:06:18,310 --> 00:06:23,980
, на которых может быть проведено тестирование.

82
00:06:23,980 --> 00:06:27,570
Один из таких фреймворков приложений называется Selenium Framework,

83
00:06:27,570 --> 00:06:31,720
который используется для автоматического тестирования в браузерах.

84
00:06:31,720 --> 00:06:36,021
Если вы используете Chrome как часть вашей стратегии тестирования или Firefox,

85
00:06:36,021 --> 00:06:39,119
, то вы можете использовать то, что называется прямым подключением.

86
00:06:39,119 --> 00:06:43,502
Это доступно через Protractor для прямого подключения к этим браузерам и

87
00:06:43,502 --> 00:06:45,828
проводить тестирование в этих браузерах.

88
00:06:45,828 --> 00:06:50,273
Теперь сами тесты используют структуру корректировки для

89
00:06:50,273 --> 00:06:51,790
, выражающей тест.

90
00:06:51,790 --> 00:06:55,450
Таким образом, вы все равно увидите, что пользователь описывает int и

91
00:06:55,450 --> 00:06:58,810
перед каждым, что вы видели с модульными тестами.

92
00:06:58,810 --> 00:07:04,332
За исключением того, что теперь мы будем использовать поддержку транспортира для

93
00:07:04,332 --> 00:07:09,119
, чтобы генерировать реальные пользовательские взаимодействия с нашим приложением

94
00:07:09,119 --> 00:07:11,157
с помощью кода.

95
00:07:11,157 --> 00:07:15,363
Так вот что мы узнаем в упражнении, которое следует за этой конкретной лекцией

96
00:07:15,363 --> 00:07:15,979
.

97
00:07:15,979 --> 00:07:21,324
Мы будем использовать Protractor и писать наши сквозные стратегии тестирования.

98
00:07:21,324 --> 00:07:24,815
И, конечно же, используйте поддержку Angular CLI для

99
00:07:24,815 --> 00:07:29,983
проведения сквозных тестов в упражнении, которое следует за этой лекцией.

100
00:07:29,983 --> 00:07:32,969
[МУЗЫКА]