From 2ce7bcc8449c6ed93f0e32c4511fe0af5b7fdae6 Mon Sep 17 00:00:00 2001 From: Sri Harsha Date: Wed, 19 Feb 2020 14:06:39 +0530 Subject: [PATCH] Modify: [EN]-> [FR] tanslating WebDriver-Understanding the components document Signed-off-by: Sri Harsha --- .../understanding_the_components.fr.md | 144 +++++++++--------- 1 file changed, 69 insertions(+), 75 deletions(-) diff --git a/docs_source_files/content/webdriver/understanding_the_components.fr.md b/docs_source_files/content/webdriver/understanding_the_components.fr.md index 13185fd029a5..0724d76787cd 100644 --- a/docs_source_files/content/webdriver/understanding_the_components.fr.md +++ b/docs_source_files/content/webdriver/understanding_the_components.fr.md @@ -3,78 +3,72 @@ title: "Comprendre les composants" weight: 1 --- -{{% notice info %}} - Page being translated from -English to French. Do you speak French? Help us to translate -it by sending us pull requests! -{{% /notice %}} - -Building a test suite using WebDriver will require you to understand and -effectively use a number of different components. As with everything in -software, different people use different terms for the same idea. Below is -a breakdown of how terms are used in this description. - -### Terminology - -* **API:** Application Programming Interface. This is the set of "commands" -you use to manipulate WebDriver. -* **Library:** A code module which contains the APIs and the code necessary -to implement them. Libraries are specific to each language binding, eg .jar -files for Java, .dll files for .NET, etc. -* **Driver:** Responsible for controlling the actual browser. Most drivers -are created by the browser vendors themselves. Drivers are generally -executable modules that run on the system with the browser itself, -not on the system executing the test suite. (Although those may be the -same system.) _NOTE: Some people refer to the drivers as proxies._ -* **Framework:** An additional library used as a support for WebDriver -suites. These frameworks may be test frameworks such as JUnit or NUnit. -They may also be frameworks supporting natural language features such -as Cucumber or Robotium. Frameworks may also be written and used for -things such as manipulating or configuring the system under test, data -creation, test oracles, etc. - - -### The Parts and Pieces -At its minimum, WebDriver talks to a browser through a driver. Communication -is two way: WebDriver passes commands to the browser through the driver, and -receives information back via the same route. - -![Basic communication](/images/basic_comms.png?width=400px) - -The driver is specific to the browser, such as ChromeDriver for Google's -Chrome/Chromium, GeckoDriver for Mozilla's Firefox, etc. The driver runs on -the same system as the browser. This may, or may not be, the same system where -the tests themselves are executing. - -This simple example above is _direct_ communication. Communication to the -browser may also be _remote_ communication through Selenium Server or -RemoteWebDriver. RemoteWebDriver runs on the same system as the driver -and the browser. - -![Remote communication](/images/remote_comms.png?width=400px) - -Remote communication can also take place using Selenium Server or Selenium -Grid, both of which in turn talk to the driver on the host system - -![Remote communication with Grid](/images/remote_comms_server.png?width=400px) - -## Where Frameworks fit in - -WebDriver has one job and one job only: communicate with the browser via any -of the methods above. WebDriver doesn't know a thing about testing: it doesn't -know how to compare things, assert pass or fail, and it certainly doesn't know -a thing about reporting or Given/When/Then grammar. - -This is where various frameworks come in to play. At a minimum you'll need a -test framework that matches the language bindings, eg NUnit for .NET, JUnit -for Java, RSpec for Ruby, etc. - -The test framework is responsible for running and executing your WebDriver -and related steps in your tests. As such, you can think of it looking akin -to the following image. - -![Test framework](/images/test_framework.png?width=400px) - -Natural language frameworks/tools such as Cucumber may exist as part of that -Test Framework box in the figure above, or they may wrap the Test Framework -entirely in their own implementation. +Pour créer une suite de tests à l'aide de WebDriver, vous devrez comprendre et +utiliser efficacement un certain nombre de composants différents. +logiciel, différentes personnes utilisent des termes différents pour la même idée. +une ventilation de la façon dont les termes sont utilisés dans cette description. + +### Terminologie + +* **API:** Interface de programmation d'application. Il s'agit de l'ensemble des "commandes" +vous utilisez pour manipuler WebDriver. +* **Bibliothèque:** Un module de code qui contient les API et le code nécessaires +Les bibliothèques sont spécifiques à chaque liaison de langue, par exemple .jar +fichiers pour Java, fichiers .dll pour .NET, etc. +* **Pilote:** Responsable du contrôle du navigateur actuel. +sont créés par les fournisseurs de navigateurs eux-mêmes. +modules exécutables qui s'exécutent sur le système avec le navigateur lui-même, +pas sur le système exécutant la suite de tests (bien que ceux-ci puissent être +même système.) _NOTE: Certaines personnes se réfèrent aux pilotes en tant que proxies._ +* **Framework:** Une bibliothèque supplémentaire utilisée comme support pour WebDriver +Ces cadres peuvent être des cadres de test tels que JUnit ou NUnit. +Il peut également s'agir de cadres prenant en charge les fonctionnalités du langage naturel telles que +comme Cucumber ou Robotium.Frameworks peut également être écrit et utilisé pour +des choses telles que la manipulation ou la configuration du système sous test, les données +création, test d'oracles, etc. + +### Les pièces et pièces + +Au minimum, WebDriver communique avec un navigateur via un pilote. +est à double sens: WebDriver passe des commandes au navigateur via le pilote, et +reçoit des informations via le même itinéraire. + +![Communication de base](/images/basic_comms.png?width=400px) + +Le pilote est spécifique au navigateur, tel que ChromeDriver pour Google +Chrome / Chrome, GeckoDriver pour Firefox de Mozilla, etc. Le pilote fonctionne sur +le même système que le navigateur. Il peut s'agir ou non du même système sur lequel +les tests eux-mêmes sont en cours d'exécution. + +Cet exemple simple ci-dessus est la communication _directe_. +le navigateur peut également être une communication à _distance_ via Selenium Server ou +RemoteWebDriver. RemoteWebDriver fonctionne sur le même système que le pilote +et le navigateur. + +![Communication à distance](/images/remote_comms.png?width=400px) + +La communication à distance peut également avoir lieu à l'aide de Selenium Server ou Selenium +Grille, qui à son tour parlent au conducteur sur le système hôte + +![Communication à distance avec Grid](/images/remote_comms_server.png?width=400px) + +## Où les cadres s'intègrent + +WebDriver a un seul travail et un seul travail: communiquez avec le navigateur via +des méthodes ci-dessus.WebDriver ne sait rien du test: il ne sait pas +savoir comparer les choses, affirmer réussir ou échouer, et il ne sait certainement pas +une chose à propos de la grammaire Reporting ou Given / When / Then. + +C'est là que divers frameworks entrent en jeu. Au minimum, vous aurez besoin d'un +cadre de test qui correspond aux liaisons de langage, par exemple NUnit pour .NET, JUnit +pour Java, RSpec pour Ruby, etc. + +Le framework de test est responsable de l'exécution et de l'exécution de votre WebDriver +et les étapes connexes dans vos tests. En tant que tel, vous pouvez penser qu'il ressemble à +à l'image suivante. + +![Cadre de test](/images/test_framework.png?width=400px) + +Des cadres / outils en langage naturel tels que le concombre peuvent exister dans le cadre de cette +Test Framework cadre dans la figure ci-dessus, ou ils peuvent envelopper le Test Framework +entièrement dans leur propre mise en œuvre.