Modify:[EN]->[FR] Translating guidelines and recommendations

docs_source_files/content/guidelines_and_recommendations/fresh_browser_per_test.fr.md

@@ -3,17 +3,11 @@ title: "Nouveau navigateur par test"
 weight: 9
 ---
 
-{{% notice info %}}
-<i class="fas fa-language"></i> Page being translated from 
-English to French. Do you speak French? Help us to translate
-it by sending us pull requests!
-{{% /notice %}}
-
-Start each test from a clean known state.
-Ideally, spin up a new virtual machine for each test.
-If spinning up a new virtual machine is not practical,
-at least start a new WebDriver for each test.
-For Firefox, start a WebDriver with your known profile.
+Commencez chaque test à partir d'un état connu propre.
+Idéalement, faites tourner une nouvelle machine virtuelle pour chaque test.
+Si la rotation d'une nouvelle machine virtuelle n'est pas pratique,
+démarrez au moins un nouveau WebDriver pour chaque test.
+Pour Firefox, démarrez un WebDriver avec votre profil connu.
 
 ```java
 FirefoxProfile profile = new FirefoxProfile(new File("pathToFirefoxProfile"));

docs_source_files/content/guidelines_and_recommendations/improved_reporting.fr.md

@@ -3,19 +3,13 @@ title: "Reporting amélioré"
 weight: 5
 ---
 
-{{% notice info %}}
-<i class="fas fa-language"></i> Page being translated from 
-English to French. Do you speak French? Help us to translate
-it by sending us pull requests!
-{{% /notice %}}
-
-Selenium is not designed to report on the status of test cases
-run. Taking advantage of the built-in reporting capabilities of unit
-test frameworks is a good start.  Most unit test frameworks have
-reports that can generate xUnit or HTML formatted reports.  xUnit
-reports are popular for importing results to a Continuous Integration
-(CI) server like Jenkins, Travis, Bamboo, etc.  Here are some links
-for more information regarding report outputs for several languages.
+Le sélénium n'est pas conçu pour rendre compte de l'état des cas de test
+courir. Profitant des capacités de rapport intégrées de l'unité
+les cadres de test sont un bon début. La plupart des cadres de tests unitaires ont
+rapports pouvant générer des rapports au format xUnit ou HTML. xUnit
+les rapports sont populaires pour importer des résultats dans une intégration continue
+(CI) comme Jenkins, Travis, Bamboo, etc. Voici quelques liens
+pour plus d'informations sur les sorties de rapports pour plusieurs langues.
 <!-- TODO: Add links.-->
 [NUnit 3 Console Runner](//github.com/nunit/docs/wiki/Console-Runner)
 [NUnit 3 Console Command Line](//github.com/nunit/docs/wiki/Console-Command-Line)

docs_source_files/content/guidelines_and_recommendations/test_independency.fr.md

@@ -3,25 +3,19 @@ title: "Indépendence des tests"
 weight: 7
 ---
 
-{{% notice info %}}
-<i class="fas fa-language"></i> Page being translated from 
-English to French. Do you speak French? Help us to translate
-it by sending us pull requests!
-{{% /notice %}}
+Écrivez chaque test comme sa propre unité. Écrivez les tests d'une manière qui ne sera pas
+dépendant d'autres tests pour effectuer:
 
-Write each test as its own unit. Write the tests in a way that will not be
-reliant on other tests to complete:
-
-Let us say there is a content management system with which you can create
-some custom content which then appears on your website as a module after 
-publishing, and it may take some time to sync between the CMS and the 
+Disons qu'il existe un système de gestion de contenu avec lequel vous pouvez créer
+du contenu personnalisé qui apparaît ensuite sur votre site Web sous forme de module après
+la publication et la synchronisation entre le CMS et le serveur peut prendre un certain temps.
 application.
 
-A wrong way of testing your module is that the content is created and 
-published in one test, and then checking the module in another test. This 
-is not feasible as the content may not be available immediately for the 
-other test after publishing.
+Une mauvaise façon de tester votre module est que le contenu est créé et
+publié dans un test, puis vérifier le module dans un autre test. Cette
+n'est pas réalisable car le contenu peut ne pas être disponible immédiatement pour le
+autre test après publication.
 
-Instead, you can create a stub content which can be turned on and off 
-within the affected test, and use that for validating the module. However,
-for content creation, you can still have a separate test.
+Au lieu de cela, vous pouvez créer un contenu de stub qui peut être activé et désactivé
+dans le test affecté, et utilisez-le pour valider le module. cependant,
+pour la création de contenu, vous pouvez toujours avoir un test séparé.