1
00:00:00,000 --> 00:00:04,307
[MUSIQUE]

2
00:00:04,307 --> 00:00:09,895
Dans la conférence précédente et l'exercice qui a suivi la conférence,

3
00:00:09,895 --> 00:00:14,330
nous avons examiné l'utilisation des tests unitaires dans Angular.

4
00:00:14,330 --> 00:00:18,920
Nous avons vu comment les différentes parties de notre application Angular, les composants,

5
00:00:18,920 --> 00:00:26,420
les services, les directives, les tuyaux peuvent tous être testés en utilisant des tests unitaires.

6
00:00:26,420 --> 00:00:27,000
Mais bien sûr, les tests unitaires

7
00:00:27,000 --> 00:00:32,550
ne révèlent pas tout sur l'interaction entre les composants.

8
00:00:32,550 --> 00:00:37,090
C'est là que les stratégies de test de bout en bout nous permettent de

9
00:00:37,090 --> 00:00:42,480
voir l'application entière fonctionner comme une seule unité.

10
00:00:42,480 --> 00:00:49,200
Donc, dans cette conférence, nous allons examiner l'utilisation des tests de bout en bout et

11
00:00:49,200 --> 00:00:54,950
quel rôle ils jouent dans la stratégie globale de test pour nos applications Angular.

12
00:00:54,950 --> 00:01:01,592
Dans l'exercice qui suit, nous allons examiner brièvement comment nous pouvons effectuer des tests

13
00:01:01,592 --> 00:01:06,160
de bout en bout pour notre application Angular, à l'aide d'un outil appelé Protractor.

14
00:01:08,110 --> 00:01:13,710
Comme nous l'avons déjà appris dans la conférence précédente, les tests unitaires

15
00:01:13,710 --> 00:01:19,650
nous offrent une merveilleuse occasion de tester nos unités en isolement.

16
00:01:19,650 --> 00:01:25,105
S'assurer que nos unités exécutent ce qu'elles sont censées effectuer,

17
00:01:25,105 --> 00:01:29,446
leur logique est correcte, et l'interaction entre le composant et

18
00:01:29,446 --> 00:01:33,720
son modèle est bien établie.

19
00:01:33,720 --> 00:01:43,720
Mais bien sûr, les tests unitaires ne complètent pas l'image entière du fonctionnement d'une application Angular typique.

20
00:01:43,720 --> 00:01:47,807
Vous n'avez pas d'unités individuelles travaillant isolément.

21
00:01:47,807 --> 00:01:51,293
Au lieu de cela, vos composants interagissent avec les services.

22
00:01:51,293 --> 00:01:53,573
Les composants peuvent utiliser des types.

23
00:01:53,573 --> 00:01:58,503
Les services, à leur tour, interagiront avec le backend pour récupérer les données.

24
00:01:58,503 --> 00:02:02,300
Et puis le composant lui-même sera responsable du rendu

25
00:02:02,300 --> 00:02:06,670
des vues en utilisant les modèles pour le composant.

26
00:02:06,670 --> 00:02:13,686
Alors, comment tout cet ensemble d'unités fonctionne-t-il ensemble ?

27
00:02:13,686 --> 00:02:18,485
Et comment faire en sorte que le travail ensemble de ces unités

28
00:02:18,485 --> 00:02:22,202
soit complètement exempt de problèmes ?

29
00:02:22,202 --> 00:02:26,931
C'est donc là que les tests de bout en bout et en cours de route, les tests d'intégration

30
00:02:26,931 --> 00:02:32,780
nous aident à couvrir ce genre de scénarios.

31
00:02:32,780 --> 00:02:39,190
Bien sûr, les tests unitaires jouent un rôle important dans la stratégie globale de test.

32
00:02:39,190 --> 00:02:42,133
Mais sans faire de tests de bout en bout,

33
00:02:42,133 --> 00:02:47,852
nous ne pouvons pas être complètement sûrs que notre application fonctionne comme prévu.

34
00:02:47,852 --> 00:02:52,697
Une chose que je dois souligner est que les tests unitaires sont rapides et

35
00:02:52,697 --> 00:02:56,790
très faciles à répéter et peuvent être effectués plusieurs fois.

36
00:02:56,790 --> 00:03:01,861
Les tests d'intégration et les tests de bout en bout sont lents, et ils sont donc utilisés

37
00:03:01,861 --> 00:03:08,390
seulement avec parcimonie pour confirmer que votre application fonctionne comme prévu.

38
00:03:08,390 --> 00:03:11,830
Donc, quand nous regardons notre stratégie globale de test,

39
00:03:11,830 --> 00:03:16,070
, nous pouvons considérer qu'elle est organisée sous la forme d'une pyramide.

40
00:03:16,070 --> 00:03:19,940
Au bas de la pyramide, occupant toute la base et

41
00:03:19,940 --> 00:03:25,251
formant la base de notre stratégie globale de test, sont des tests unitaires.

42
00:03:26,710 --> 00:03:31,790
Comme nous l'avons appris, les tests unitaires nous permettent de tester les unités individuelles en isolement,

43
00:03:31,790 --> 00:03:35,460
en s'assurant que leur logique et

44
00:03:35,460 --> 00:03:39,970
la façon dont ces unités fonctionnent sont correctes.

45
00:03:39,970 --> 00:03:42,890
Et ces tests peuvent être répétés très fréquemment.

46
00:03:42,890 --> 00:03:48,040
Et en effet, devrait être répété fréquemment pour s'assurer que les unités

47
00:03:48,040 --> 00:03:49,610
individuelles fonctionnent comme prévu.

48
00:03:50,630 --> 00:03:57,850
Bien sûr, à un deuxième niveau de cette stratégie, il y aurait des tests d'intégration.

49
00:03:57,850 --> 00:04:02,600
Comment un petit groupe d'unités travaillent ensemble dans

50
00:04:02,600 --> 00:04:07,680
implémentant tout ce qui est nécessaire pour être fait par ces groupes d'unités ?

51
00:04:07,680 --> 00:04:12,460
Alors peut-être que nous pourrions tester un composant avec

52
00:04:12,460 --> 00:04:17,730
ses services pour voir comment le flux d'informations entre eux se produit.

53
00:04:17,730 --> 00:04:22,880
Mais au sommet de cette pyramide se trouve des tests de bout en bout où

54
00:04:22,880 --> 00:04:25,320
nous regardons l'application globale.

55
00:04:25,320 --> 00:04:29,880
Et comment l'application globale est performante et

56
00:04:29,880 --> 00:04:32,890
répond aux exigences attendues.

57
00:04:32,890 --> 00:04:36,990
C'est donc là que nous voyons l'utilisation de tests de bout en bout.

58
00:04:36,990 --> 00:04:42,680
Comme vous pouvez déjà vous y attendre par ce diagramme, les tests de bout en bout sont lents.

59
00:04:42,680 --> 00:04:48,584
Et donc nous n'effectuons pas de tests de bout en bout très fréquemment, au lieu de cela, le test unitaire

60
00:04:48,584 --> 00:04:55,412
constitue la stratégie de base pour nos tests de notre application Angular.

61
00:04:55,412 --> 00:05:02,149
Les tests de bout en bout contribuent à l'image globale, mais ils ne le sont pas souvent

62
00:05:02,149 --> 00:05:08,021
, mais ils sont toujours un élément essentiel de notre stratégie de test.

63
00:05:08,021 --> 00:05:10,852
Alors, comment faire des tests de bout en bout ?

64
00:05:10,852 --> 00:05:15,210
Parlons brièvement des outils disponibles pour nous.

65
00:05:15,210 --> 00:05:18,199
L'environnement de test angulaire pour les tests de bout en bout

66
00:05:18,199 --> 00:05:23,740
est pris en charge par un outil nommé Protractor.

67
00:05:23,740 --> 00:05:27,930
Qui dit que les geeks n'ont pas le sens de l'humour ?

68
00:05:27,930 --> 00:05:30,950
Rapporteur, Angulaire, voilà.

69
00:05:30,950 --> 00:05:33,450
Alors qu'est-ce que c'est exactement Protractor ?

70
00:05:33,450 --> 00:05:37,500
Protractor est, comme vous pouvez vous y attendre, un programme de noeud.

71
00:05:37,500 --> 00:05:40,940
Cela nous permet donc d'effectuer des tests de bout en bout.

72
00:05:40,940 --> 00:05:45,510
Donc, Protractor exécute les tests contre votre application.

73
00:05:45,510 --> 00:05:49,800
Donc Protractor charge votre application dans un navigateur et interagit avec

74
00:05:49,800 --> 00:05:54,570
l'application tout comme un utilisateur réel interagira avec votre application.

75
00:05:54,570 --> 00:05:59,160
Nous cherchons donc à interagir avec votre application,

76
00:05:59,160 --> 00:06:03,410
bien que par programmation, mais en effectuant le genre d'opérations que

77
00:06:03,410 --> 00:06:07,500
un utilisateur typique effectuera comme cliquer sur des liens, remplir des formulaires.

78
00:06:07,500 --> 00:06:13,110
Soumettre des formulaires, naviguer vers différentes parties de votre demande et ainsi de suite.

79
00:06:13,110 --> 00:06:18,310
C'est donc là que Protractor exploite l'utilisation d'un WebDriver pour contrôler les navigateurs

80
00:06:18,310 --> 00:06:23,980
sur lesquels les tests peuvent être effectués.

81
00:06:23,980 --> 00:06:27,570
Un tel framework d'application est appelé le Selenium Framework,

82
00:06:27,570 --> 00:06:31,720
qui est utilisé pour faire des tests automatisés dans les navigateurs.

83
00:06:31,720 --> 00:06:36,021
Si vous utilisez Chrome dans le cadre de votre stratégie de test ou Firefox,

84
00:06:36,021 --> 00:06:39,119
alors vous pouvez utiliser ce qu'on appelle une connexion directe.

85
00:06:39,119 --> 00:06:43,502
qui est disponible via un rapporteur pour se connecter directement à ces navigateurs et

86
00:06:43,502 --> 00:06:45,828
effectuer des tests dans ces navigateurs.

87
00:06:45,828 --> 00:06:50,273
Maintenant, les tests eux-mêmes tirent parti du cadre d'ajustement pour

88
00:06:50,273 --> 00:06:51,790
exprimant le test.

89
00:06:51,790 --> 00:06:55,450
Donc, vous verrez toujours l'utilisateur décrire un int et

90
00:06:55,450 --> 00:06:58,810
avant chacun que vous avez vu avec des tests unitaires.

91
00:06:58,810 --> 00:07:04,332
Sauf que maintenant, nous allons tirer parti du support du rapporteur pour que

92
00:07:04,332 --> 00:07:09,119
puisse générer de vraies interactions de type utilisateur avec notre application

93
00:07:09,119 --> 00:07:11,157
en utilisant du code.

94
00:07:11,157 --> 00:07:15,363
C'est donc ce que nous allons apprendre dans l'exercice qui suit cette conférence

95
00:07:15,363 --> 00:07:15,979
particulière.

96
00:07:15,979 --> 00:07:21,324
Nous ferons usage de Protractor et écrirons nos stratégies de test de bout en bout.

97
00:07:21,324 --> 00:07:24,815
Et bien sûr, tirez parti du support de l'interface de ligne de commande Angular pour

98
00:07:24,815 --> 00:07:29,983
effectuer des tests de bout en bout dans l'exercice qui suit cette conférence.

99
00:07:29,983 --> 00:07:32,969
[MUSIQUE]