update based on https://github.com/mdn/yari/issues/2028

author: Peter Bengtsson <mail@peterbe.com> 2020-12-08 21:46:22 -0500
committer: Peter Bengtsson <mail@peterbe.com> 2020-12-08 21:46:22 -0500
commit: a065e04d529da1d847b5062a12c46d916408bf32 (patch)
tree: fe0f8bcec1ff39a3c499a2708222dcf15224ff70 /files/fr/archive/b2g_os/automated_testing
parent: 218934fa2ed1c702a6d3923d2aa2cc6b43c48684 (diff)
download: translated-content-a065e04d529da1d847b5062a12c46d916408bf32.tar.gz
translated-content-a065e04d529da1d847b5062a12c46d916408bf32.tar.bz2
translated-content-a065e04d529da1d847b5062a12c46d916408bf32.zip
18 files changed, 0 insertions, 1992 deletions
diff --git a/files/fr/archive/b2g_os/automated_testing/configurer_marionette/index.html b/files/fr/archive/b2g_os/automated_testing/configurer_marionette/index.html
deleted file mode 100644
index 8ae67abda9..0000000000
--- a/files/fr/archive/b2g_os/automated_testing/configurer_marionette/index.html
+++ /dev/null
@@ -1,48 +0,0 @@
----
-title: Configurer Marionette pour Firefox OS
-slug: Archive/B2G_OS/Automated_testing/Configurer_Marionette
-tags:
-  - Firefox OS
-  - Guide
-translation_of: 'https://marionette-client.readthedocs.io/en/latest/'
----
-<h2 id="Configurer_le_client_Marionette">Configurer le client Marionette</h2>
-
-<p>Le client Marionette est un package Python avec lequel vous pouvez exécuter des tests Marionette : à la fois des tests Python et des tests de WebAPI JavaScript. Vous allez avoir besoin de configurer ceci sur votre machine avant de pouvoir l'utiliser.</p>
-
-<p>Pour y parvenir, vous devez cloner un arbre Gecko ; soit l'arbre Gecko dans un clone Firefox OS, soit un clone Gecko autonome (par exemple, <a href="http://hg.mozilla.org/mozilla-central/" title="http://hg.mozilla.org/mozilla-central/">mozilla-central</a>). Par exemple, supposons que c'est la première fois que vous clonez un arbre Gecko :</p>
-
-<p>Installez tout d'abord Mercurial, si ce n'est déjà fait. Voici comment vous pouvez faire sur Mac si vous avez Homebrew d'installé. Les autres gestionnaires de package seront différents :</p>
-
-<p><code>$ brew install mercurial</code></p>
-
-<p>Déplacez-vous dans votre répertoire de travail (par exemple ~/code) et tapez la ligne suivante pour commencer le processus de clonage :</p>
-
-<p><code>$ hg clone http://hg.mozilla.org/mozilla-central/ $GECKO_DIR</code></p>
-
-<p>... où $GECKO_DIR peut être n'importe quel nom valide de répertoire, par exemple <code>mozilla-central</code>. Cette étape va prendre un peu de temps (environ 10 minutes avec une connexion rapide).</p>
-
-<p>Voir assi <a href="/en-US/docs/Mozilla/Firefox_OS/Building_and_installing_Firefox_OS">Compiler et installer Firefox OS</a> pour plus de détails sur la façon de configurer un environnement de compilation Firefox OS et faire un <em>pull</em> du code.</p>
-
-<pre>$ cd $GECKO_DIR/testing/marionette/client
-
-$ python setup.py develop</pre>
-
-<p>Il est recommandé d'utiliser un environnement virtuel <a href="/en-US/docs/Python/Virtualenv" title="/en-US/docs/Python/Virtualenv">virtualenv</a>. Configuration rapide de virtualenv :</p>
-
-<p><code>$ pip install virtualenv</code></p>
-
-<p><code>$ virtualenv $MARIONETTE_ENV</code></p>
-
-<p>Encore une fois, <code>$MARIONETTE_ENV</code> peut être n'importe quel nom valide de répertoire. Maintenant vous devriez être capable d'exécuter les étapes ci-dessus mais dans le nouvel environnement avec :</p>
-
-<pre>$ cd $GECKO_DIR/testing/marionette/client
-
-$ $MARIONETTE_ENV/bin/python setup.py develop</pre>
-
-<p>Pour vérifier que Marionette est installé :</p>
-
-<pre>$ $MARIONETTE_ENV/bin/python
-&gt;&gt;&gt; from marionette import Marionette</pre>
-
-<p>Voir aussi <a href="/en-US/docs/Marionette/Running_Tests" title="/en-US/docs/Marionette/Running_Tests">Exécuter des tests Marionette</a> pour plus d'informations sur la façon d'exécuter des tests après avoir configuré Marionette.</p>
diff --git a/files/fr/archive/b2g_os/automated_testing/endurance/index.html b/files/fr/archive/b2g_os/automated_testing/endurance/index.html
deleted file mode 100644
index dc39c6ae1d..0000000000
--- a/files/fr/archive/b2g_os/automated_testing/endurance/index.html
+++ /dev/null
@@ -1,153 +0,0 @@
----
-title: Endurance tests
-slug: Archive/B2G_OS/Automated_testing/Endurance
-translation_of: Archive/B2G_OS/Automated_testing/Endurance
----
-<div class="warning">
-<p><strong>Important</strong>:<strong> </strong>Les tests d'endurance Gaia-ui ne sont plus utilisés - voir <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1117144" title="FIXED: Remove gaia-ui endurance tests">bug 1117144</a> - cette page est maintenu seulement pour la valeur historique. Vous devriez regarder nos <a href="https://developer.mozilla.org/en-US/Firefox_OS/Automated_testing/MTBF_tests">tests MTBF</a> place.</p>
-</div>
-
-<div class="summary">
-<p>Le but de nos tests d'endurance est de vérifier Firefox OS et la stabilité de l'application Gaia et de détecter des fuites de mémoire, en effectuant de multiples itérations de cas d'utilisation communes. Les tests d'endurance Gaia-IU sont en cours d'exécution dans l'ombre, tandis que d'autres types de tests d'endurance sont actuellement en développement (et seront ajoutés ici quand ils serontt mis en ligne). Cet article explique comment ces tests fonctionnent, et comment les exécuter.</p>
-</div>
-
-<p><span id="result_box" lang="fr"><span class="alt-edited">Les tests d'endurance Gaia-IU sont une suite de tests de Firefox OS construits au-dessus du cadre <a href="https://developer.mozilla.org/en-US/Firefox_OS/Automated_testing/gaia-ui-tests">Gaiatest (Tests de l'IU Gaia)</a>. Les tests s'exécutent sur de vrais dispositifs de Firefox OS, et utilisent <a href="https://developer.mozilla.org/en-US/docs/Mozilla/QA/Marionette">Marionette </a>pour  conduire l'IU de l'appareil.</span></span></p>
-
-<p>Comme mentionné ci-dessus, les tests d'endurance Gaia-IU vérifie  le dispositif Firefox OS et la stabilité de l'application Gaia  en effectuant plusieurs itérations de cas d'utilisation communes. Des exemples de ces cas d'utilisation comprennent l'ajout d'un contact dans le carnet d'adresses, d'ajouter un événement au calendrier, l'envoi d'un message SMS, ouvrant le navigateur Firefox et la navigation sur un site spécifique.</p>
-
-<p>As well as verifying Gaia application functionality under numerous iterations, the endurance tests also perform device-side "checkpoints" after every <em>N</em> number of iterations. This checkpoint currently consists of recording the device’s B2G process RSS memory use value. By logging these results over time and comparing them across commits and builds, we can to detect any sudden changes in B2G memory consumption that may occur during the various test scenarios.</p>
-
-<h2 id="Running_the_tests">Running the tests</h2>
-
-<div class="note">
-<p><strong>Note</strong>: The Gaia-UI Endurance tests and framework source code can be found in the "v1-train" branch of the <a href="https://github.com/mozilla-b2g/gaia/tree/v1-train/tests/python/gaia-ui-tests/gaiatest/tests/endurance" title="https://github.com/mozilla-b2g/gaia/tree/v1-train/tests/python/gaia-ui-tests/gaiatest/tests/endurance">Mozilla Github Gaia repository</a>.</p>
-</div>
-
-<p>Let's go through the steps required to set up the Gaia-UI Endurance test environment and run the tests on your local machine and Firefox OS device.</p>
-
-<div class="warning">
-<p><strong>WARNING: Running the Gaia-UI Endurance Tests will result in data being ERASED from the Firefox OS device, including data on the device’s microSD card</strong>. Therefore, if there is any data on your Firefox OS device and microSD card that you wish to keep, be sure to back it up first before running the Gaia-UI Endurance Tests. Consider yourself warned!</p>
-</div>
-
-<h3 id="Prerequisites">Prerequisites</h3>
-
-<ul>
- <li>Ubuntu 12.04 (or better) x64, or Mac OS X (these instructions are confirmed for 10.8 but should work on previous versions of 10, theoretically.)</li>
- <li>A Firefox OS device ALREADY FLASHED with an ENGINEERING build of Firefox OS B2G. As the Endurance tests are underpinned by the well maintained gaiatest, compatibility with a range of devices and branches is good.</li>
- <li><a href="/en-US/Firefox_OS/Debugging/Installing_ADB">ADB installed</a>, and the environment variable <code>ADB_PATH</code> pointing to your ADB location.</li>
-</ul>
-
-<p>If you are on Ubuntu, you need to check that it is configured to support the USB connection to the Firefox OS device. To verify this, connect the device to your computer via USB, open a terminal and enter the <code>adb logcat</code> command to see if it connects.</p>
-
-<div class="note">
-<p><strong>Note</strong>: To start with, the Firefox OS device should not be connected to your computer. You will be told when to connect it in the steps below.</p>
-</div>
-
-<h3 id="Step_1_Clone_the_Gaia_repository">Step 1: Clone the Gaia repository</h3>
-
-<p>The Gaia-UI Endurance Tests are located in the Mozilla Github Gaia repository. Assuming that you haven’t done so already, the first step is to clone that repo:</p>
-
-<pre>git clone <a href="https://github.com/mozilla-b2g/gaia.git" rel="nofollow">https://github.com/mozilla-b2g/gaia.git</a></pre>
-
-<p>You may want to go grab a coffee and come back in five minutes.</p>
-
-<h3 id="Step_2_Run_the_GaiaTest_setup">Step 2: Run the GaiaTest setup</h3>
-
-<p>The Gaia-UI Endurance tests are built upon the GaiaTest framework (which uses <a href="https://developer.mozilla.org/en-US/docs/Marionette" title="Marionette">Marionette</a>). The next step is to run the setup script to install GaiaTest and all of the required dependencies. You may wish to create a new virtual environment to use with the Gaia-UI Endurance Tests. If you don’t, you may need to use <code>sudo</code> while running the setup command. In your terminal, type:</p>
-
-<pre style="padding-left: 30px;">cd gaia/tests/python/gaia-ui-tests
-python setup.py develop</pre>
-
-<h3 id="Step_3_Set_test_vars_and_acknowledge_risks">Step 3: Set test vars and acknowledge risks</h3>
-
-<p>GaiaTest uses a special file to set certain variables that are required for test configuration. For example, to tell the device which WiFi network it should use. Before running the Gaia-UI Endurance Tests, you must setup the test vars file. Make a copy of the <code>gaia/tests/python/gaia-ui-tests/gaiatest/testvars_template.json</code> file in the same location (call it what you like) and edit it:</p>
-
-<ul>
- <li>If the Firefox OS device has a SIM card, add the corresponding phone number in the phone number entry in the <code>carrier</code> section, e.g. <code>"phone_number": "5551234567"</code>.</li>
- <li>Add the same phone number for the <code>"remote_phone_number"</code> entry.</li>
- <li>In the <code>wifi</code> section, add the SSID for the Wifi network that the Firefox OS device is to connect to during the tests in the <code>ssid</code> line, for example <code>"ssid": "Wifi Network Name"</code>.</li>
-</ul>
-
-<p>As mentioned in the warning above, running the Gaia-UI Endurance tests will result in data being erased from the Firefox OS device and microSD card. This is to ensure that the tests start cleanly each time. For example, running a test on a device that already has 10,000 contacts will have very different memory value results vs running the same test on a device with no existing contacts. In order to run the tests, you must acknowledge that you are aware of this data loss risk.</p>
-
-<p>To acknowledge the risks, add the following entry to your <code>testvars</code> file as the first entry in the list: <code>"acknowledged_risks": true</code>.</p>
-
-<div class="note">
-<p><strong>Note</strong>: If the risks are not acknowledged in the <code>testvars</code> file, the tests will not run.</p>
-</div>
-
-<h3 id="Step_4_Connect_the_device_to_WiFi">Step 4: Connect the device to WiFi</h3>
-
-<p>Next, power on your Firefox OS device. After it boots up, go into the Wifi settings then manually select and connect to the Wifi network that you want the device to use for the tests. Ensure the Wifi settings confirm that the device is connected to Wifi before continuing.</p>
-
-<h3 id="Step_5_Connect_to_USB_and_ADB_Forward_the_Device">Step 5: Connect to USB and ADB Forward the Device</h3>
-
-<p>Attach the Firefox OS device to your computer via USB.</p>
-
-<div class="note">
-<p><strong>Note</strong>: If you’re using an Ubuntu VM, after attaching the device ensure the VM sees the device and connects to it; in the VM select <em>VM &gt; Removable Devices &gt; Your Device &gt; Connect</em> and wait for the device to connect to the VM.</p>
-</div>
-
-<p>Now tell <code>adb</code> to forward the device port to GaiaTest using the following command:</p>
-
-<pre class="brush: bash" style="padding-left: 30px;">adb forward tcp:2828 tcp:2828</pre>
-
-<div class="note">
-<p><strong>Note</strong>: If you are using the Firefox OS Leo device, you must first tell ADB to be the root user, like so:</p>
-
-<pre style="padding-left: 30px;">adb root
-adb forward tcp:2828 tcp:2828</pre>
-</div>
-
-<h3 id="Step_6_Run_a_Test">Step 6: Run a Test</h3>
-
-<p>Now you’re ready to actually try running a test. To run the <code>add_contact</code> endurance test, with a single iteration, use the following commands:</p>
-
-<pre class="brush: bash" style="padding-left: 30px;">cd gaia/tests/python/gaia-ui-tests
-gaiatest --type=b2g --address=localhost:2828 --testvars=mytestvars.json --iterations=1 --checkpoint=1 --restart gaiatest/tests/endurance/test_endurance_add_contact.py</pre>
-
-<p>If you get a “connection refused” error it means the device USB connection didn’t work; just repeat the device connection and try again.</p>
-
-<p>The Firefox OS device b2g process should now restart, then the <code>add_contact</code> endurance test will run with a single iteration. If you watch the Firefox OS device, you’ll see the device UI being manipulated by Marionette. After the test finishes, a memory checkpoint will be performed.</p>
-
-<div class="note">
-<p><strong>Note</strong>: The Gaia-UI Endurance tests now grab the Firefox OS device’s b2g process RSS value for the memory use checkpoint (it used to be the V-SIZE value.)</p>
-</div>
-
-<p>The test result will be displayed in the terminal window. Note that this result doesn’t include the b2g process memory value; this value is stored in a text file that was created at the time of the checkpoint in the <code>checkpoints</code> directory. To see the resulting b2g process, open this file. This "suite_summary" file will contain the average b2g process memory use (RSS) value, averaged from all of the test checkpoints (in our example there was only one checkpoint anyway).</p>
-
-<p>There are two other files present in the <code>checkpoints</code> folder:</p>
-
-<ul>
- <li>The <code>checkpoint_add_contact_(datetime)_summary.log</code> file contains a summary for the test run. This includes the number of iterations, all of the RSS value readings from each checkpoint, the average RSS value, etc.</li>
- <li>The <code>checkpoint_add_contact_(datetime).log</code> file contains the raw data received from each of the device checkpoints, from which the summary files were produced.</li>
-</ul>
-
-<h3 id="Command_Line_Options">Command Line Options</h3>
-
-<p>Here is a description of the GaiaTest command line options that you can use when running the Gaia-UI Endurance Test(s):</p>
-
-<ul>
- <li style="padding-left: 30px;"><code>--type</code>: The type of test being run; always use <code>--type=b2g</code> for this.</li>
- <li style="padding-left: 30px;"><code>--address</code>: The address where the device port is forwarded, when you issued the ADB forward command; just use <code>--address=localhost:2828</code>.</li>
- <li style="padding-left: 30px;"><code>--testvars</code>: The path and name of the file containing the test vars, as described in Step 3 above.</li>
- <li style="padding-left: 30px;"><code>--iterations</code>: The number of times to repeat each test case/test; i.e. 100 iterations of the <code>add_contact</code> test will result in 100 new address book entries being added.</li>
- <li style="padding-left: 30px;"><code>--checkpoints</code>: After every <em>N</em> iterations a b2g process memory checkpoint will be grabbed from the device; by default a checkpoint will be performed after all iterations are complete.</li>
- <li style="padding-left: 30px;"><code>--restart</code>: The Firefox OS device’s b2g process will be restarted before each new test (not each iteration) begins (i.e. a soft reset.)</li>
-</ul>
-
-<p>As an example, to run the <code>add_contact</code> test and have it perform 100 test case iterations, grabbing a device memory checkpoint after every 10 iterations, and restarting the b2g process before the test begins, you would use the following command line:</p>
-
-<pre class="brush: bash" style="padding-left: 30px;">gaiatest --type=b2g --address=localhost:2828 --testvars=mytestvars.json --iterations=100 --checkpoint=10 --restart gaiatest/tests/endurance/test_endurance_add_contact.py</pre>
-
-<p>If you wish to run the entire Gaia-UI Endurance test suite, instead of specifying a single test on the command line, just point to the manifest file for the test name, like this:</p>
-
-<pre class="brush: bash" style="padding-left: 30px;">gaiatest --type=b2g --address=localhost:2828 --testvars=mytestvars.json --iterations=1 --checkpoint=1 --restart gaiatest/tests/endurance/manifest.ini</pre>
-
-<p>However, note that running the entire test suite, with 100 iterations of each test (and a checkpoint after every 10 iterations) takes approximately 16 hours.</p>
-
-<p>Now you should be all set and have the Gaia-UI Endurance Tests up and running on your local machine/device.</p>
-
-<h2 id="Contributing_to_the_project">Contributing to the project</h2>
-
-<p>If you have any questions about the Firefox OS Endurance tests or are interested in contributing to this important automation development effort, feel free to contact us in the Mozilla #automation IRC channel.</p>
diff --git a/files/fr/archive/b2g_os/automated_testing/gaia-ui-tests/index.html b/files/fr/archive/b2g_os/automated_testing/gaia-ui-tests/index.html
deleted file mode 100644
index 92bef3f84c..0000000000
--- a/files/fr/archive/b2g_os/automated_testing/gaia-ui-tests/index.html
+++ /dev/null
@@ -1,74 +0,0 @@
----
-title: Gaia UI Tests Introduction
-slug: Archive/B2G_OS/Automated_testing/gaia-ui-tests
-tags:
-  - B2G
-  - Build documentation
-  - Firefox OS
-  - Gaia
-  - Guide
-  - Mobile
-  - Testing
-  - TopicStub
-  - gaia-ui-test
-  - gaiatest
-translation_of: Archive/B2G_OS/Automated_testing/gaia-ui-tests
----
-<div class="prevnext" style="text-align: right;">
-<p><a href="/fr/docs/Mozilla/Firefox_OS/Platform/Automated_testing/gaia-ui-tests/Part_1_Marionette_Firefox_OS_start">Suivant »</a></p>
-</div>
-
-
-
-<div class="summary">
-<p>Gaia-ui-tests est la suite de tests Mozilla, qui permet de tester le rendu final de l'interface utilisateur pour Gaia, l'interface utilisateur de Firefox OS. Tous les tests sont écrits en Python avec un peu de JavaScript utilisé pour interagir avec les API Firefox OS. Cette série d'articles explique comment configurer l'environnement pour écrire et lancer des tests.</p>
-</div>
-
-<p>Gaia-ui-tests utilise <strong>Gaiatest</strong>, un package Python basé autour de <a href="https://developer.mozilla.org/en-US/docs/Marionette" title="https://developer.mozilla.org/en-US/docs/Marionette">Marionette</a>. Gaiatest est concu pour réunir, les cibles HTML, les appels Marionette, et les appels API pour une communication et un fonctionnement inter-opérable. Marionette est basé sur le standard W3C développé pour le <a href="http://docs.seleniumhq.org/projects/webdriver/" title="http://docs.seleniumhq.org/projects/webdriver/">Selenium WebDriver</a> une interface de programmation pour l'automatisation du navigateur. Si vous avez déjà utilisé WebDriver ainsi que des objets de page/application auparavant, alors l'utilisation de Marionette et gaiatest vous paraitront facile.</p>
-
-<h2 id="Démarrer_avec_Gaia_UI_tests">Démarrer avec Gaia UI tests</h2>
-
-<p>Pour ceux qui désirent débuter avec les tests automatisés sur Gaia/Firefox OS, nous avons une séries de tutoriels, qui vous aideront de zéro, jusqu'à écrire vos propres tests. Une fois que vous aurez achevé ce tutoriel, vous aurez assez de connaissance en tests Firefox OS et Marionette, pour contribuer aux tests Mozilla. <strong>Il est fortement recommandé de suivre l'ensemble de ce tutoriel, si vous souhaitez devenir contributeur.</strong></p>
-
-<dl>
- <dt><a href="/fr/Firefox_OS/Automated_testing/gaia-ui-tests/Partie_1_Marionette_Firefox_OS_commencer">Partie 1: Bien commencer avec Marionette et Firefox OS</a></dt>
- <dd>Cet article couvre l'installation des outils nécessaire pour démarrer avec les tests, comme le Bureau B2G, Python et Marionette.</dd>
- <dt><a href="/fr/Firefox_OS/Automated_testing/gaia-ui-tests/Partie_2_Marionette_Firefox_OS_interactions">Partie 2 : Interactions de base avec Firefox OS via l'utilisation de Marionette</a></dt>
- <dd>Un apperçu des commandes de base, que vous utiliserez, pour manipuler Firefox OS avec Marionette.</dd>
- <dt><a href="/fr/Firefox_OS/Automated_testing/gaia-ui-tests/Partie_3_Tests_reutilisables">Partie 3 : Améliorer notre code pour en faire un test réutilisable</a></dt>
- <dd>Pour continuer, dans cet article, nous allons assembler quelques commandes de base dans un test simple, à l'intérieur d'un fichier Python, afin qu'ils puissent tous être gérés comme une seule entité.</dd>
- <dt><a href="/fr/Firefox_OS/Automated_testing/gaia-ui-tests/Partie_4_Reutiliser_commandes_Firefox_OS_configuration">Partie 4 : Réutiliser des commandes pour configurer Firefox OS</a></dt>
- <dd>Ici, nous allons déplacer certaines des commandes, dans les méthodes de Python, pour promouvoir la réutilisation du code.</dd>
- <dt><a href="/fr/Firefox_OS/Automated_testing/gaia-ui-tests/Partie_5_Introduction_executeur_tests">Partie 5 : Introduction à un exécuteur de tests</a></dt>
- <dd>Un lanceur de test est un élément central de toute bonne suite de tests, vous permettant d'exécuter de multiples tests, et d'obtenir un rapport et des résultats globaux. Dans cet article, nous allons explorer les bases du lanceur unittest de Python.</dd>
- <dt><a href="/fr/Firefox_OS/Automated_testing/gaia-ui-tests/Partie_6_Marionette_classe_By">Partie 6: Utiliser des tuples, et la classe By de Marionette</a></dt>
- <dd>Cette fois, nous expliquons comment réduire encore la duplication de code, en stockant les localisateurs répétées dans tuples et simplifiant la syntaxe avec la classe <code>By</code> de Marionette.</dd>
- <dt><a href="/fr/Firefox_OS/Automated_testing/gaia-ui-tests/Partie_7_Ecrire_vos_propres_tests">Partie 7 : Écrire vos propres tests</a></dt>
- <dd>Maintenant, les bases sont derrière vous, et il est temps de commencer à écrire vos propres tests! Nous vous donnons ici quelques recommandations d'outils pour vous faciliter le travail, et proposons des tests pour vous exercer à en écrire.</dd>
- <dt><a href="/fr/Firefox_OS/Automated_testing/gaia-ui-tests/Partie_8_Utiliser_une_classe_base">Partie 8 : Utiliser une classe base</a></dt>
- <dd>Dans son état actuel, notre fichier de test contient tout le code du lanceur de test. Ceci va bien pour le moment, mais dès que vous commencez à exécuter de nombreux fichiers de test, cela signifie beaucoup de doublons. Ici, nous résolvons ce problème, en faisant abstraction du code du lanceur de test, dans une classe Python séparée.</dd>
- <dt><a href="/fr/Firefox_OS/Automated_testing/gaia-ui-tests/Partie_9_objets_app">Partie 9 : Réduire le code dupliqué avec des objets app</a></dt>
- <dd>Comme amélioration finale à la maintenabilité du code, dans cet article, nous explorons le code d'abstraction, qui gère l'interaction avec les applications spécifiquent à Firefox OS, dans des objets d'applications Python.</dd>
-</dl>
-
-<h2 id="Sujets_avancés">Sujets avancés</h2>
-
-<p>Une fois que vous possédez les bases pour écrire et lancer des tests, vous pourriez vouloir avancer pour des travaux avec plus d'implications ou plus avancés, comme lancer la suite de tests complète gaia-ui-tests, ou connecter l'énergie résultante de la suite d'un test.</p>
-
-<dl>
- <dt><a href="https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/Platform/Automated_testing/gaia-ui-tests/Gaia_UI_Tests_Run_Tests" title="Gaia UI Tests Run Tests">Lancer le gaia-ui-tests</a></dt>
- <dd>Des guides pour lancer la suite gaia-ui-tests sur des vrais périphériques Firefox OS et <a href="/en-US/Firefox_OS/Using_the_B2G_desktop_client">Le Bureau B2G</a> dans diverses configurations.</dd>
-</dl>
-
-<h2 id="Voir_aussi">Voir aussi</h2>
-
-<p><a href="https://github.com/mozilla-b2g/gaia/tree/master/tests/python/gaia-ui-tests">Repo principal Gaia-ui-tests</a></p>
-
-<h2 id="QuestionsCommentairesPréoccupations_2"><span class="mw-headline" id="QuestionsCommentairesPréoccupations">Questions/Commentaires/Préoccupations </span></h2>
-
-<p>Ce projet est à un stade d'avancement précoce, et vos retours d'expérience sont grandement appréciés :</p>
-
-<ul>
- <li>Envoyer des mails à la liste <a href="http://mailto:_gaia-ui-automation@mozilla.org">gaia-ui-automation@mozilla.org</a>.</li>
- <li>Sinon, retrouvez nous sur <a href="https://wiki.mozilla.org/IRC">l'IRC Mozilla</a> dans les canaux #fxosqa, #fxos-automation, et #moztpeqa.</li>
-</ul>
diff --git a/files/fr/archive/b2g_os/automated_testing/gaia-ui-tests/partie_1_marionette_firefox_os_commencer/index.html b/files/fr/archive/b2g_os/automated_testing/gaia-ui-tests/partie_1_marionette_firefox_os_commencer/index.html
deleted file mode 100644
index 6747a2a1dc..0000000000
--- a/files/fr/archive/b2g_os/automated_testing/gaia-ui-tests/partie_1_marionette_firefox_os_commencer/index.html
+++ /dev/null
@@ -1,129 +0,0 @@
----
-title: 'Partie 1: Bien commencer avec Marionette et Firefox OS'
-slug: >-
-  Archive/B2G_OS/Automated_testing/gaia-ui-tests/Partie_1_Marionette_Firefox_OS_commencer
-tags:
-  - Automatisation
-  - interface utilisateur
-translation_of: >-
-  Archive/B2G_OS/Automated_testing/gaia-ui-tests/Part_1_Marionette_Firefox_OS_start
----
-<p></p><div class="prevnext" style="text-align: right;">
-    <p><a href="/fr/docs/Mozilla/Firefox_OS/Platform/Automated_testing/gaia-ui-tests" style="float: left;">« Précédent</a><a href="/fr/docs/Mozilla/Firefox_OS/Platform/Automated_testing/gaia-ui-tests/Part_2_Marionette_Firefox_OS_interactions">Suivant  »</a></p>
-</div><p></p>
-
-<div class="summary">
-<p><span class="seoSummary">Cette série de tutoriels a pour objectif de vous familiariser avec l'écriture et l'exécution des tests automatisés de l'interface utilisateur pour Firefox OS en utilisant <a href="/en-US/docs/Mozilla/QA/Marionette">Marionette</a>, un package d'automatisation qui tourne sur votre ordinateur. Marionette publie des commandes pour exécuter des tests sur les plateformes basées sur Gecko. Cet article va vous faire parcourir plus particulièrement la configuration que vous devez effectuer avant d'exécuter des tests.</span></p>
-</div>
-
-<p>La série de tutoriels va parcourir les concepts de l'automatisation de tests et aussi vous familiariser au travail avec Firefox OS (y compris le très utile outil de test <a href="/en-US/Firefox_OS/Using_the_B2G_desktop_client">B2G Desktop</a>) et Marionette. Occasionnellement, nous présenterons quelques défis pour vous encourager à explorer vos propres solutions.</p>
-
-<div class="note">
-<p><strong>Note </strong>: le tutoriel n'est pas spécifique aux produits de Mozilla ; par exemple, si vous développez une application HTML5, vous pouvez utiliser ce tutoriel pour constuire un framework de tests.</p>
-</div>
-
-<h2 id="Logiciels_requis_pour_ce_tutoriel">Logiciels requis pour ce tutoriel</h2>
-
-<p>Au cours de ce tutoriel, nous allons installer et utiliser les logiciels suivants :</p>
-
-<ul>
- <li>Python 2.7</li>
- <li>pip installer</li>
- <li>Un éditeur de texte ou IDE pour écrire le code</li>
- <li>Le client de bureau Boot2Gecko (Firefox OS)</li>
- <li>Le client Marionette (client WebDriver pour Firefox OS)</li>
-</ul>
-
-<h2 id="Python_et_pip">Python et pip</h2>
-
-<p>Des systèmes d'exploitation comme Linux auront Python déjà préinstallé. Avant d'installer Python, vérifiez qu'il n'est pas déjà installé. Depuis une ligne de commande ou un terminal, exécutez :</p>
-
-<pre class="brush: bash">python --version</pre>
-
-<p>Toute version de Python 2.6.x ou 2.7.x est valable pour ce tutoriel. Si vous n'avez pas Python 2.7 d'installé, vous pouvez trouver l'installeur sur le <a href="https://www.python.org/download/releases/2.7.6/">site de téléchargement de Python</a>.</p>
-
-<p>Pip est utilisé pour installer les outils Python et nous en avons besoin pour installer Marionette. Vous pouvez vérifier si pip est installé en saisissant <code>pip</code> dans votre terminal ou votre ligne de commande. Pour installer pip, suivez les instructions dans la <a href="http://pip.readthedocs.org/en/latest/installing.html">documentation pip</a>.<br>
-  </p>
-
-<h2 id="Bureau_B2G">Bureau B2G</h2>
-
-<p>Le client de bureau B2G vous permet d'exécuter Gaia — l'interface utilisateur de Firefox OS — et les applications Firefox OS sur un bureau d'ordinateur. Le client de bureau possède certaines limites — il n'émule pas le matériel de l'appareil comme l'appareil photo, la batterie, etc. — mais il sera parfait pour les sujets de ce tutoriel. Allez, installons-le maintenant.</p>
-
-<p>Téléchargez la dernière version du bureau B2G depuis le <a href="http://nightly.mozilla.org/">site Firefox Nightly</a> (voir Desktop Boot2Gecko, en bas). Dès que le bureau B2G est téléchargé, extraire les contenus dans un dossier sur votre ordinateur. Pour démarrer le simulateur Firefox OS exécutez le fichier script <strong>b2g</strong> approprié à votre système d'exploitation :</p>
-
-<ul>
- <li><strong>Linux</strong> : naviguez vers le dossier où vous l'avez extrait et exécutez <code>./b2g</code></li>
- <li><strong>Mac </strong>: glissez et déplacez B2G.app dans votre dossier Application et exécutez-le depuis celui-ci.</li>
- <li><strong>Windows </strong>: exécutez b2g.exe depuis le dossier où vous avez extrait le zip.</li>
-</ul>
-
-<p>Dès que l'application démarre, vous devriez voir une fenêtre similaire à celle-ci :</p>
-
-<p><img alt="A welcome screen for Firefox OS - says welcome in multiple languages" src="https://mdn.mozillademos.org/files/7207/b2g-start-screen.png" style="width: 322px; height: 509px; display: block; margin: 0px auto;"></p>
-
-<p>Suivez les étapes de Premier Usage jusqu'à arriver sur l'écran d'accueil Firefox OS. Notez que vous pouvez émuler les boutons du téléphone en utilisant les commandes clavier suivantes, qui peuvent être parfois utiles (par exemple, appuyer sur Home pour éviter que le téléphone ne se mette en veille).</p>
-
-<table class="standard-table">
- <thead>
-  <tr>
-   <th scope="row">
-    <p> </p>
-   </th>
-   <th scope="col">
-    <p>Clavier Windows/Linux</p>
-   </th>
-   <th scope="col">
-    <p>Clavier Mac OS</p>
-   </th>
-  </tr>
- </thead>
- <tbody>
-  <tr>
-   <th scope="row">
-    <p>Bouton Home</p>
-   </th>
-   <td>
-    <p>Home</p>
-   </td>
-   <td>
-    <p>Fn + flèche gauche</p>
-   </td>
-  </tr>
-  <tr style="height: 0px;">
-   <th scope="row">
-    <p>Bouton Power</p>
-   </th>
-   <td>
-    <p>Fin</p>
-   </td>
-   <td>
-    <p>Fn + flèche droite</p>
-   </td>
-  </tr>
-  <tr>
-   <th scope="row">
-    <p>Volume haut/bas</p>
-   </th>
-   <td>
-    <p>Haut/Bas de page</p>
-   </td>
-   <td>
-    <p>Fn+ flèche haut/bas</p>
-   </td>
-  </tr>
- </tbody>
-</table>
-
-<p>À cette étape, vous pouvez laisser ouvert le bureau B2G et mettre la fenêtre de coté. Maintenant nous allons terminer le travail en installant Marionette.</p>
-
-<h2 id="Marionette">Marionette</h2>
-
-<p>Marionette est constitué de deux parties ; le client — qui fonctionne sur votre ordinateur — et le serveur — qui fonctionne à l'intérieur de Firefox OS. Le serveur Marionette, comme un marionnettiste, peut contrôler directement Firefox OS.</p>
-
-<p><img alt="marionette architecture showing marionette server inside Firefox OS and marionette client on its own outside" src="https://mdn.mozillademos.org/files/7223/marionette-basic-diagram.png" style="width: 352px; height: 186px; display: block; margin: 0px auto;"></p>
-
-<p>Puisque nous utilisons le client bureau B2G, le serveur Marionette est préinstallé (cela est aussi vrai quand vous utilisez une compilation préconfigurée de Firefox OS sur un appareil réel). Avant toutefois de pouvoir contrôler Firefox OS, nous devons installer le client Marionette sur notre ordinateur. On peut le faire en exécutant la commande suivante dans le terminal :</p>
-
-<pre class="brush: bash">pip install marionette_client</pre>
-
-<p>C'est tout pour le moment. Nous avons tout configuré et sommes prêts à commencer !</p>
diff --git a/files/fr/archive/b2g_os/automated_testing/gaia-ui-tests/partie_2_marionette_firefox_os_interactions/index.html b/files/fr/archive/b2g_os/automated_testing/gaia-ui-tests/partie_2_marionette_firefox_os_interactions/index.html
deleted file mode 100644
index 04eed2587c..0000000000
--- a/files/fr/archive/b2g_os/automated_testing/gaia-ui-tests/partie_2_marionette_firefox_os_interactions/index.html
+++ /dev/null
@@ -1,120 +0,0 @@
----
-title: >-
-  Partie 2 : Interactions de base avec Firefox OS via l'utilisation de
-  Marionette
-slug: >-
-  Archive/B2G_OS/Automated_testing/gaia-ui-tests/Partie_2_Marionette_Firefox_OS_interactions
-tags:
-  - Automatisation
-  - interface utilisateur
-translation_of: >-
-  Archive/B2G_OS/Automated_testing/gaia-ui-tests/Part_2_Marionette_Firefox_OS_interactions
----
-<p></p><div style="text-align: right;" class="prevnext">
-    <p><a style="float: left;" href="/fr/docs/Mozilla/Firefox_OS/Platform/Automated_testing/gaia-ui-tests/Part_1_Marionette_Firefox_OS_start">« Précédent</a><a href="/fr/docs/Mozilla/Firefox_OS/Platform/Automated_testing/gaia-ui-tests/Part_3_Reusable_tests">Suivant  »</a></p>
-</div><p></p>
-
-<div class="summary">
-<p><span class="seoSummary">Dans la deuxième partie de notre tutoriel nous allons débuter avec des commandes Marionette simples qui vont nous permettre de contrôler à distance Firefox OS. Même si nous n'allons pas couvrir l'écriture d'un test en intégralité, cet article vous enseigne les fonctionnalités basiques de code que vous pourrez utiliser pour écrire un test. Dans la troisième partie, nous irons plus loin pour faire évoluer ce code en un test réel.</span></p>
-</div>
-
-<h2 id="Démarrage_de_Firefox_OS">Démarrage de Firefox OS</h2>
-
-<p>Pour écrire ces tests vous avez besoin d'avoir Firefox OS déjà en cours d'exécution et prêt à recevoir des commandes :</p>
-
-<ol>
- <li>Démarrer le bureau B2G.</li>
- <li>Désactiver l'écran de verrouillage en utilisant <em>Paramètres &gt; Ecran de verrouillage &gt; décocher verrouiller l'écran</em>.</li>
- <li>Désactiver la mise en veille de l'écran en changeant le paramètre <em>Paramètres &gt; Affichage &gt; Ecran de veille </em>à <em>jamais</em>.</li>
- <li>Déplacer la fenêtre sur le côté en attendant les commandes de test.</li>
-</ol>
-
-<h2 id="Démarrage_de_Marionette">Démarrage de Marionette</h2>
-
-<p>Maintenant nous allons démarrer une console Python : allez simplement dans une fenêtre de terminal et tapez la commande <code>python</code>.</p>
-
-<p>Depuis cette console nous pouvons envoyer des commandes au serveur Marionette dans Firefox OS. Après avoir saisi les commandes qui suivent vous devriez voir répondre Firefox OS. Dans la console Python, entrez la commande suivante pour importer la librairie Marionette contenant le code dont nous avons besoin :</p>
-
-<pre class="brush: bash">from marionette import Marionette</pre>
-
-<p>Exécutez maintenant les deux lignes suivantes, qui débutent une session Marionette et le préparent à recevoir des commandes de la part du client :</p>
-
-<pre class="brush: bash">marionette = Marionette()
-marionette.start_session()</pre>
-
-<p>Si vous ne désactivez pas l'écran de verrouillage comme expliqué ci-dessus, vous pouvez déverrouiller l'écran  en ligne de commande, en utilisant :</p>
-
-<pre class="brush: bash">marionette.execute_script('window.wrappedJSObject.lockScreen.unlock();')</pre>
-
-<h2 id="Accès_à_différents_cadres_dans_Firefox_OS">Accès à différents cadres dans Firefox OS</h2>
-
-<p>Les applications web dans Firefox OS opèrent dans différents iFrames. Exécuter des applications web dans des cadres séparés leur donnent des conteneurs différents pour la gestion de la sécurité et du visuel (comme une fenêtre). Vous pouvez imaginer que cela fonctionne comme un bac à sable dans lequel l'application s'exécute. Marionette ne peut fonctionner que dans un seul cadre à la fois. Nous avons besoin de Marionette pour passer dans le cadre avec lequel nous voulons interagir.</p>
-
-<p>Le cadre du haut est aussi l'application Système. Toutes les applications et leurs cadres sont des filles de l'application Système. Notre nouvelle session Marionette commence dans le cadre Système mais pour commencer le test nous devons passer dans l'écran d'accueil.</p>
-
-<p>Pour trouver le iFrame, nous devons d'abord l'identifier. Comme Marionette est basée sur l'API WebDriver, elle utilise les mêmes stratégies pour localiser des éléments, donc nous pouvons utiliser une de ces stratégies pour identifier les éléments web de WebDriver. Pour plus d'informations, lire <a href="http://www.w3.org/TR/webdriver/#element-location-strategies">element location strategies</a>.</p>
-
-<p>Dans ce cas, nous allons utiliser le sélecteur CSS <code>div.homescreen iframe</code> pour sélectionner le iFrame de l'écran d'accueil ; la fonction <code>find_element()</code> le prend comme deuxième argument, le premier étant une définition du mécanisme de sélection utilisé pour faire la recherche. Nous allons ensuite stocker ce résultat dans une variable et exécuter la fonction <code>switch_to_frame()</code> avec la variable comme argument. À présent, essayez les deux commandes suivantes :</p>
-
-<pre class="brush: bash"># Switch context to the homescreen iframe and tap on the Contacts app icon
-home_frame = marionette.find_element('css selector', 'div.homescreen iframe')
-marionette.switch_to_frame(home_frame)</pre>
-
-<div class="note">
-<p><strong>Note</strong>: Pour plus d'informations et de diagrammes décrivant le changement de cadres, vous pouvez lire <a href="https://blog.mozilla.org/webqa/2013/02/13/part-2-ui-testing-on-firefox-os-working-with-iframes/">Working with iFrames</a>.</p>
-</div>
-
-<h2 id="Ouverture_d'une_application">Ouverture d'une application</h2>
-
-<p>OK. Maintenant que nous nous trouvons dans l'application Homescreen nous pouvons cibler les icônes et les cliquer en utilisant la fonction <code>find_element()</code>, combinée avec la fonction <code>tap()</code>.</p>
-
-<pre class="brush: bash"><code>contacts_icon = marionette.find_element('xpath', "</code><code>//div[@class='icon']//span[contains(text(),'Contacts')]")</code>
-contacts_icon.tap()</pre>
-
-<p>Si tout se passe bien, vous devriez maintenant avoir l'application Contacts ouverte, mais nous devons encore passer dans cadre de l'application Contacts pour interagir avec lui, comme nous l'avions fait précédemment avec l'écran d'accueil :</p>
-
-<pre class="brush: bash"># First, we need to switch context back to the System frame
-marionette.switch_to_frame()
-
-# Now, switch context to the contacts app frame
-contacts_frame = marionette.find_element('css selector', "iframe[data-url*='contacts']")
-marionette.switch_to_frame(contacts_frame)</pre>
-
-<p>Passer dans le cadre devrait renvoyer <code>True</code>. Si c'est le cas, c'est super ! Cela signifie que nous sommes dans le contexte de l'application Contacts et que nous sommes prêts à l'utiliser.</p>
-
-<h2 id="Manipulation_de_l'application">Manipulation de l'application</h2>
-
-<p>Dans la prochaine étape, nous allons réaliser une tâche de test typique — créer un nouveau contact, lui entrer un nom, et le sauvegarder. Premièrement, nous allons appuyer sur le bouton d'ajout d'un contact :</p>
-
-<pre class="brush: bash"># Tap [+] to add a new Contact
-marionette.find_element('id', 'add-contact-button').tap()</pre>
-
-<p>Maintenant, ajoutons le nom du contact en utilisant les deux commandes suivantes (<code>send_keys()</code> est utilisée pour insérer une valeur dans un élément) :</p>
-
-<pre class="brush: bash">marionette.find_element('id', 'givenName').send_keys('Foo')
-# Add the contact's surname
-marionette.find_element('id', 'familyName').send_keys('Bar')</pre>
-
-<p>À présent, appuyons sur le bouton OK pour sauvegarder le contact :</p>
-
-<pre class="brush: bash"><code class="language-html">marionette.find_element('id', 'save-button').tap()</code></pre>
-
-<p>Vous devriez voir un nouveau contact entré dans l'application Contacts. Si c'est le cas, c'est parfait !</p>
-
-<div class="note">
-<p><strong>Note </strong>: si ce n'est pas le cas, redémarrez ou tuez l'application Contacts, retournez sur l'écran d'accueil et essayez d'exécuter la tâche de nouveau.</p>
-</div>
-
-<h2 id="Fermeture_de_votre_session_Marionette">Fermeture de votre session Marionette</h2>
-
-<p>Pour finir, vous devez fermer votre session Marionette en saisissant la commande suivante :</p>
-
-<pre class="brush: bash">marionette.delete_session()</pre>
-
-<p>Tout cela a bien fonctionné, mais vous ne pouvez pas taper dans une console Python à chaque fois que vous voulez exécuter un test ! Dans la partie 3, nous allons compiler ce script dans un fichier Python que nous pourrons réutiliser à chaque fois que l'on voudra exécuter un test. Nous ajouterons également une ligne pour déterminer si le test a réussi ou échoué.</p>
-
-<div class="note">
-<p><strong>Note </strong>: lors de l'écriture des commandes Marionette, vous avez certainement remarqué que l'accès à la structure HTML sous-jacente de l'application est vitale pour comprendre les repères dont vous avez besoin. <a href="https://developer.mozilla.org/en-US/Firefox_OS/Platform/Automated_testing/gaia-ui-tests/Part_7_Writing_your_own_tests#Resources">Partie 7: Ecrire vos propres tests</a> offre quelques ressources utiles pour vous aider sur ce sujet.</p>
-</div>
-
-<p> </p>
diff --git a/files/fr/archive/b2g_os/automated_testing/gaia-ui-tests/partie_3_tests_reutilisables/index.html b/files/fr/archive/b2g_os/automated_testing/gaia-ui-tests/partie_3_tests_reutilisables/index.html
deleted file mode 100644
index b053f8cf9b..0000000000
--- a/files/fr/archive/b2g_os/automated_testing/gaia-ui-tests/partie_3_tests_reutilisables/index.html
+++ /dev/null
@@ -1,131 +0,0 @@
----
-title: 'Partie 3 : Améliorer notre code pour en faire un test réutilisable'
-slug: Archive/B2G_OS/Automated_testing/gaia-ui-tests/Partie_3_Tests_reutilisables
-tags:
-  - Firefox OS
-  - Marionette
-  - Python
-  - test
-translation_of: Archive/B2G_OS/Automated_testing/gaia-ui-tests/Part_3_Reusable_tests
----
-<p></p><div style="text-align: right;" class="prevnext">
-    <p><a style="float: left;" href="/fr/docs/Mozilla/Firefox_OS/Platform/Automated_testing/gaia-ui-tests/Part_2_Marionette_Firefox_OS_interactions">« Précédent</a><a href="/fr/docs/Mozilla/Firefox_OS/Platform/Automated_testing/gaia-ui-tests/Part_4_Reusing_commands_Firefox_OS_setup">Suivant  »</a></p>
-</div><p></p>
-
-<div class="summary">
-<p><span class="seoSummary">Nous avons appris dans la partie 2 que nous pouvions contrôler de manière simple Firefox OS en utilisant les commandes du client Marionette. Néanmoins, les saisir dans une console Python est aussi lent que fastidieux. L'avantage clé de l'automatisation de tests est son exécution autonome. Nous allons apprendre comment faire cela dans cette partie, en mettant toutes nos commandes dans un fichier Python qui pourra s'exécuter d'un seul coup.</span></p>
-</div>
-
-<h2 id="Résumé_d'un_cas_de_test">Résumé d'un cas de test</h2>
-
-<p>Dans la partie 2, nous avons passé les étapes pour exécuter un cas de test typique — ouvrir l'application Contacts et ajouter un nouveau contact :</p>
-
-<ol>
- <li>Déverrouiller Firefox OS (facultatif ; dans la partie 2 nous avons désactivé l'écran de verrouillage manuellement, en conséquence nous ne l'incluerons pas dans le code ci-dessous)</li>
- <li>Aller dans l'application Contacts</li>
- <li>Appuyer sur l'icône d'ajout d'un nouveau contact</li>
- <li>Saisir le nom du contact</li>
- <li>Appuyer sur OK</li>
- <li>Attendre et vérifier que le contact est présent</li>
-</ol>
-
-<h2 id="Mettre_notre_test_dans_un_fichier_Python">Mettre notre test dans un fichier Python</h2>
-
-<p>Si nous mettons toutes ces étapes dans un fichier Python, nous pouvons le réutiliser et l'exécuter bien plus rapidement. Créez un nouveau fichier texte nommé <code>test_add_contact.py</code> dans un dossier convenable de votre choix.</p>
-
-<p>Dans ce fichier, entrez les commandes que nous avons vues dans la partie 2, comme listé ci-dessous. Nous utiliserons une structure de classes Python, puisque c'est une bonne pratique et qui plus est elle constitue une bonne base pour construire les étapes à venir de ce tutoriel.</p>
-
-<pre class="brush: python">import time
-from marionette import Marionette
-
-class TestContacts:
-
-    def __init__(self):
-        self.test_add_contacts()
-
-    def test_add_contacts(self):
-        # Create the client for this session. Assuming you're using the default port on a Marionette instance running locally
-        self.marionette = Marionette()
-        self.marionette.start_session()
-
-        # Switch context to the homescreen iframe and tap on the contacts icon
-        time.sleep(2)
-        home_frame = self.marionette.find_element('css selector', 'div.homescreen iframe')
-        self.marionette.switch_to_frame(home_frame)
-        contacts_icon = self.marionette.find_element('xpath', "//div[@class='icon']//span[contains(text(),'Contacts')]")
-        contacts_icon.tap()
-
-        # Switch context back to the base frame
-        self.marionette.switch_to_frame()
-        time.sleep(2)
-
-        # Switch context to the contacts app
-        contacts_frame = self.marionette.find_element('css selector', "iframe[data-url*='contacts']")
-        self.marionette.switch_to_frame(contacts_frame)
-
-        # Tap [+] to add a new Contact
-        self.marionette.find_element('id', 'add-contact-button').tap()
-        time.sleep(2)
-
-        # Type name into the fields
-        self.marionette.find_element('id', 'givenName').send_keys('John')
-        self.marionette.find_element('id', 'familyName').send_keys('Doe')
-
-        # Tap done
-        self.marionette.find_element('id', 'save-button').tap()
-        time.sleep(2)
-
-        # Close the Marionette session now that the test is finished
-        self.marionette.delete_session()
-
-if __name__ == '__main__':
-    TestContacts()
-</pre>
-
-<div class="note">
-<p><strong>Note </strong>: il y a une chose que vous allez remarquer dans le code que nous n'avons pas couverte dans la partie 2 : la fonction Python <code>time.sleep()</code> — cela met le script en pause pour une certaine durée (définie en secondes) avant qu'il ne continue jusqu'à la ligne suivante. Nous avons ajouté ces lignes dans le test automatisé car nous devons simuler l'utilisateur qui, manuellement, appuie sur les boutons, etc. et attendre que Firefox OS effectue les actions qui en résultent. Si nous exécutons le script sans pause, Python effectuera toutes les actions de manière instantanée, mettant probablement le test en échec, puisque Firefox OS n'aurait pas été capable de s'adapter.</p>
-</div>
-
-<p>À présent, nous pouvons lancer le test en allant dans le fichier où le test est enregistré via le terminal et en exécutant la commande suivante :</p>
-
-<pre class="brush: bash">python test_add_contact.py</pre>
-
-<div class="note">
-<p><strong>Note</strong> : soyez vigilant par rapport aux règles d'identation de Python. Après avoir copié et collé le code vous devrez probablement tout identer correctement pour qu'il s'exécute. Si vous obtenez une erreur liée à ce point, assurez-vous que tous les niveaux d'indentation sont séparés par une tabulation.</p>
-</div>
-
-<div class="note">
-<p><strong>Note</strong> : vous remarquerez également que le nom inséré dans le code ci-dessus est "John Doe", à la différence du nom "Foo Bar" de la partie 2. Nous avons fait ce changement dans le code pour qu'il puisse ajouter avec succès un autre contact. Si vous essayez d'ajouter un contact avec le même nom, Firefox OS vous alertera sur le doublon de contacts. Pour l'instant, la meilleure façon de répéter l'exécution du test est d'aller dans l'interface de Firefox OS et de supprimer manuellement le contact avant chaque exécution.</p>
-</div>
-
-<h2 id="Ajouter_une_assertion">Ajouter une assertion</h2>
-
-<p>L'élément qui manque toujours dans notre test, qui est important dans les tests automatisés, est une assertion — un rapport ou mesure pour déterminer si Firefox OS a atteint l'état que nous voulions qu'il atteigne ou si le test est un succès. Nous allons régler ce problème en ajoutant du code pour vérifier si le nouveau contact est présent dans l'application.<br>
-  <br>
- Juste avant la ligne <code># Close the Marionette session…</code> ajoutez dans ce code, en s'assurant qu'il est indenté au même niveau que les autres lignes de la classe :</p>
-
-<pre class="brush: python"># Now let's find the contact item and get its text
-contact_name = self.marionette.find_element('css selector', 'li.contact-item:not([data-group$="ice"]) p').text
-assert contact_name == 'John Doe'</pre>
-
-<p>Supprimez l'ancien contact et essayer d'exécuter de nouveau le test, avec la commande suivante :</p>
-
-<pre class="brush: bash">python test_add_contact.py</pre>
-
-<p>Si cela s'exécute correctement, alors nous avons un test qui fonctionne !</p>
-
-<div class="note">
-<p><strong>Note </strong>: si l'assertion échoue, assurez-vous que le précédent contact 'Foo Bar' n'existe plus. Le sélecteur CSS avant l'assertion prend en compte le premier contact de la liste (cela pourrait être visible en appelant <code>print "Contact name: %s" % contact_name</code> avant l'appel de l'assertion).</p>
-</div>
-
-<div class="note">
-<p><strong>Note </strong>: l'assertion n'apparaîtra pas pour faire quelque chose, mais les assertions sont très importantes quand nous commençons à utiliser des exécuteurs de tests, comme présenté dans la <a href="/en-US/Firefox_OS/Platform/Automated_testing/gaia-ui-tests/Part_5_Introducing_a_test_runner">Partie 5: Présentation d'un exécuteur de tests</a>. Les exécuteurs de test comme unittest utilisent les assertions pour vérifier si les tests ont été réalisés avec succès ou non, et ensuite retournent les résultats de ces tests (OK ou FAIL.)</p>
-</div>
-
-<h2 id="Note_sur_le_timing">Note sur le timing</h2>
-
-<p>Une des choses les plus difficiles à gérer en écrivant un test automatisé est le timing. Si le test passe à l'étape suivant avant que Firefox OS n'effectue la précédente, alors nous allons probablement avoir un échec du test.<br>
-  <br>
- Comme mentionné ci-dessus, dans l'exemple de code que nous avons ajouté, la commande <code>time.sleep(x)</code> résout ce problème. Pourtant, utiliser <code>time.sleep(x)</code> n'est pas une bonne pratique. Utiliser une temporisation codée en dur peut faire que le test va s'exécuter trop longtemps ou pas assez. Le dernier cas est le pire ; il donnera des résultats de tests faux négatifs — ce qui signifie un test qui remonte un échec quand en réalité l'application fonctionne parfaitement mais se comporte de manière plus lente que ce que le test espérait.</p>
-
-<p>Dans la partie suivante, nous aborderons l'abstraction de certains points du test vers des fonctions Pythons distinctes,  et remplacerons les fonctions <code>sleep()</code> par les temporisations dynamiques appropriées.</p>
diff --git a/files/fr/archive/b2g_os/automated_testing/gaia-ui-tests/partie_4_reutiliser_commandes_firefox_os_configuration/index.html b/files/fr/archive/b2g_os/automated_testing/gaia-ui-tests/partie_4_reutiliser_commandes_firefox_os_configuration/index.html
deleted file mode 100644
index c19b0fe951..0000000000
--- a/files/fr/archive/b2g_os/automated_testing/gaia-ui-tests/partie_4_reutiliser_commandes_firefox_os_configuration/index.html
+++ /dev/null
@@ -1,108 +0,0 @@
----
-title: 'Partie 4 : Réutiliser des commandes pour configurer Firefox OS'
-slug: >-
-  Archive/B2G_OS/Automated_testing/gaia-ui-tests/Partie_4_Reutiliser_commandes_Firefox_OS_configuration
-tags:
-  - Automatisation
-  - B2G
-  - Firefox OS
-  - Gaia
-  - Marionette
-  - Python
-  - interface utilisateur
-  - test
-translation_of: >-
-  Archive/B2G_OS/Automated_testing/gaia-ui-tests/Part_4_Reusing_commands_Firefox_OS_setup
----
-<p></p><div style="text-align: right;" class="prevnext">
-    <p><a style="float: left;" href="/fr/docs/Mozilla/Firefox_OS/Platform/Automated_testing/gaia-ui-tests/Part_3_Reusable_tests">« Précédent</a><a href="/fr/docs/Mozilla/Firefox_OS/Platform/Automated_testing/gaia-ui-tests/Part_5_Introducing_a_test_runner">Suivant  »</a></p>
-</div><p></p>
-
-<div class="summary">
-<p><span class="seoSummary">Dans les parties 2 et 3 nous avons écrit un test qui fonctionne, mais si nous voulions réinitialiser son état (par exemple en tuant les applications ouvertes) avant d'exécuter le test, nous devions le faire manuellement. Ceci est un peu fastidieux, nous devrions donc automatiser ce point ! Dans cette partie, nous allons voir comment faire cela en éclatant des bouts de code dans des méthodes Python distinctes que nous pourrons réutiliser.</span></p>
-</div>
-
-<h2 id="Réinitialisation_automatique">Réinitialisation automatique</h2>
-
-<p>Avant de réaliser une exécution de test typique, nous aurons probablement besoin de déverrouiller l'écran de verrouillage de Firefox OS et tuer toutes les applications en cours d'exécution. Regardons de plus près comment faire.</p>
-
-<h3 id="Déverrouiller_l'écran_de_verrouillage">Déverrouiller l'écran de verrouillage</h3>
-
-<p>Avant d'aller plus loin, activez l'écran de verrouillage de nouveau avec <em>Paramètres &gt; Écran de verrouillage &gt; Verrouiller l'écran</em>, si ce n'est pas déjà fait.</p>
-
-<p>Ajoutez la méthode Python suivante dans votre fichier <code>test_add_contact.py</code>, juste dans la classe :</p>
-
-<pre class="brush: python">def unlock_screen(self):
-    self.marionette.execute_script('window.wrappedJSObject.lockScreen.unlock();')</pre>
-
-<p>Cette méthode va désormais déverrouiller Firefox OS quand elle sera appelée. Maintenant, appelons-la dans notre test en ajoutant les lignes suivantes sous la ligne <code>self.marionette.start_session()</code> :</p>
-
-<pre class="brush: python"># Unlock the screen
-self.unlock_screen()</pre>
-
-<h3 id="Tuer_toute_application_ouverte">Tuer toute application ouverte</h3>
-
-<p>Maintenant nous allons ajouter une méthode dans notre code pour tuer toutes les applications ouvertes. Cela ressemble à ceci :</p>
-
-<pre class="brush: python">    def kill_all(self):
-        self.marionette.switch_to_frame()
-        self.marionette.execute_async_script("""
-             // Kills all running apps, except the homescreen.
-             function killAll() {
-               let manager = window.wrappedJSObject.appWindowManager;
-
-               let apps = manager.getApps();
-               for (let id in apps) {
-                 let origin = apps[id].origin;
-                 if (origin.indexOf('verticalhome') == -1) {
-                   manager.kill(origin);
-                 }
-               }
-             };
-             killAll();
-             // return true so execute_async_script knows the script is complete
-             marionetteScriptFinished(true);
-            """)</pre>
-
-<p>Ajoutez ceci juste après la méthode <code>unlock_screen</code> que nous avons ajoutée dans la section précédente.</p>
-
-<p>Puis, ajoutez les lignes suivantes pour exécuter ceci pour le reste du test ; ajoutez ceci juste après la ligne <code>self.unlock_screen()</code> :</p>
-
-<pre class="brush: python"># kill all open apps
-self.kill_all()</pre>
-
-<p>Maintenant, essayez de laisser l'application Contacts ouverte après la dernière exécution du test et retournez à l'écran de verrouillage avant d'exécuter le test de nouveau. En plus du déverrouillage de l'écran, l'application Contacts ouverte sera automatiquement tuée avant d'exécuter de nouveau le test, donc son état n'affectera pas le test que vous êtes en train d'exécuter. Ce point est important pour la fiabilité sur le long terme de notre exécution de test.</p>
-
-<p>Exécutez de nouveau le test plusieurs fois et visualisez si tout fonctionne et si Firefox OS est réinitialisé proprement.</p>
-
-<h2 id="Attentes_dynamiques">Attentes dynamiques</h2>
-
-<p>Dans la partie 3, nous avons mentionné l'importance des attentes dynamiques. Marionette possède des attentes comme WebDriver/Selenium2, avec une syntaxe particulière qui ressemble à celle-ci :</p>
-
-<pre class="brush: python">from marionette_driver import Wait
-
-# Wait until element is displayed
-Wait(self.marionette).until(lambda m: m.find_element('id', 'element_id').is_displayed())</pre>
-
-<p>Ce code attendra jusqu'à ce que l'élément spécifié soit affiché. À ce moment, nous savons que nous sommes prêts à interagir avec lui. Essayons d'utiliser cette construction de code dans notre test.</p>
-
-<p>Tout d'abord, incluez la ligne importée Wait, juste après les lignes d'import existantes :</p>
-
-<pre class="brush: python">from marionette_driver
- import Wait</pre>
-
-<p>À présent, nous pouvons remplacer la deuxième fonction <code>time.sleep(2)</code> après avoir pressé l'icone Contacts (juste après la ligne <code>self.marionette.switch_to_frame()</code>) avec une méthode <code>Wait()</code> qui attendra jusqu'à ce que le cadre Contacts soit affiché :</p>
-
-<pre class="brush: python">Wait(self.marionette).until(lambda m: m.find_element('css selector', "iframe[data-url*='contacts']").is_displayed())</pre>
-
-<p>Quand nous appuyons sur le symbole + pour commencer la création d'un nouveau contact, nous voulons attendre que le formulaire d'ajout de contact soit complètement visible. Le bouton OK (sauvegarder) est la chose suivante que nous devons presser, nous allons donc attendre d'être mis en position avant de continuer. Remplacez la troisième fonction <code>time.sleep(2)</code> par la ligne suivante :</p>
-
-<pre class="brush: python">Wait(self.marionette).until(lambda m: m.find_element('id', 'save-button').location['y']== 0)</pre>
-
-<p>Dans cet exemple, nous attendons que le bouton OK soit déplacé en haut de l'écran ; cet élément sera visible en de nombreux points suite à l'animation, mais la postition d'arrêt finale est la position la plus sûre à attendre.</p>
-
-<p>Nous pouvons également attendre les éléments qui ne doivent pas être affichés. Après avoir appuyé sur OK, nous attendons que le bouton OK soit caché en utilisant une méthode <code>Wait()</code> similaire avec une négation, avant d'exécuter le reste du code. Remplacez la quatrième et dernière fonction <code>time.sleep(2)</code> avec ce qui suit :</p>
-
-<pre class="brush: python">Wait(self.marionette).until(lambda m: not m.find_element('id', 'save-button').is_displayed())</pre>
-
-<p>SI votre test est bon, alors c'est super ! Nous avons réalisé un test plus modulaire et fiable. Dans la partie 5, nous vous familiariserons à l'utilisation d'un exécuteur de tests.</p>
diff --git a/files/fr/archive/b2g_os/automated_testing/gaia-ui-tests/partie_5_introduction_executeur_tests/index.html b/files/fr/archive/b2g_os/automated_testing/gaia-ui-tests/partie_5_introduction_executeur_tests/index.html
deleted file mode 100644
index bd8ea4f19a..0000000000
--- a/files/fr/archive/b2g_os/automated_testing/gaia-ui-tests/partie_5_introduction_executeur_tests/index.html
+++ /dev/null
@@ -1,190 +0,0 @@
----
-title: 'Partie 5 : Introduction à un exécuteur de tests'
-slug: >-
-  Archive/B2G_OS/Automated_testing/gaia-ui-tests/Partie_5_Introduction_executeur_tests
-tags:
-  - Automatisation
-  - B2G
-  - Firefox OS
-  - Gaia
-  - Marionette
-  - Python
-  - interface utilisateur
-  - tests
-translation_of: >-
-  Archive/B2G_OS/Automated_testing/gaia-ui-tests/Part_5_Introducing_a_test_runner
----
-<p></p><div style="text-align: right;" class="prevnext">
-    <p><a style="float: left;" href="/fr/docs/Mozilla/Firefox_OS/Platform/Automated_testing/gaia-ui-tests/Part_4_Reusing_commands_Firefox_OS_setup">« Précédent</a><a href="/fr/docs/Mozilla/Firefox_OS/Platform/Automated_testing/gaia-ui-tests/Part_6_Marionette_By_class">Suivant  »</a></p>
-</div><p></p>
-
-<div class="summary">
-<p><span class="seoSummary">Jusqu'ici tout va bien, mais nous avons toujours traité un seul test. Quand on teste une réelle application web il peut y avoir des centaines de cas de tests, et nous ne voulons certainement pas exécuter chacun d'eux manuellement. Dans un tel scénario, nous devons utiliser un exécuteur de tests pour trouver et exécuter les tests à pour nous. C'est le sujet de cet article.</span></p>
-</div>
-
-<h2 id="Exécuteurs_de_tests">Exécuteurs de tests</h2>
-
-<p>Un exécuteur de tests fournit la bonne base pour un framework de test réel. Il est conçu pour exécuter des tests, des étiquettes de tests avec des attributs (annotations), fournir du reporting et bien d'autres fonctionnalités encore. Il existe de nombreux exécuteurs de tests Python disponibles, mais dans notre cas, nous allons utiliser le <strong>unittest </strong>de Python puisqu'il est simple, efficace et inclus dans le package Python (comme cela nous n'avons pas besoin d'installer quoi que ce soit).</p>
-
-<p>En général on sépare les tests en 3 sections standard : <code>setUp()</code>, tests, et <code>tearDown()</code>, typique pour une configuration d'exécuteur de tests.<br>
-  <br>
- Les méthodes <code>setUp()</code> et <code>tearDown()</code> sont exécutées automatiquement pour chaque test et contiennent respectivement :</p>
-
-<ul>
- <li>Les étapes de configuration qu'il faut réaliser avant d'exécuter le test, comme déverrouiller l'écran et tuer les applications ouvertes.</li>
- <li>Les étapes de refroidissement qu'il faut exécuter après le test, comme fermer la session Marionette.</li>
-</ul>
-
-<p>La partie test de la configuration est le code que vous voulez exécuter pour le test en cours. Regardons maintenant comment nous pouvons appliquer cela au test que nous avons construit dans les parties 2 à 4.</p>
-
-<h2 id="Exécuter_test_add_contact.py_avec_unittest">Exécuter test_add_contact.py avec unittest</h2>
-
-<p>Pour utiliser unittest nous devons tout d'abord importer unittest : ajoutez la ligne suivante en dessous de vos autres lignes d'import :</p>
-
-<pre class="brush: python">import unittest</pre>
-
-<p>Ensuite, nous devons créer un exécuteur de tests. Pour faire cela, nous allons faire hériter la classe <code>TestContacts</code> de la classe <code>unittest.Testcase</code> ; mettez à jour votre ligne <code>class</code> comme suit :</p>
-
-<pre class="brush: python">class TestContacts(unittest.TestCase):</pre>
-
-<p>Nous devons également supprimer ceci :</p>
-
-<pre class="brush: python">    def __init__(self):
-        self.test_add_contacts()</pre>
-
-<p>L'initialisation du test sera gérée à la place par unittest, ainsi nous ne devons pas le gérer nous-mêmes. A la fin du code, remplacez ce qui suit :</p>
-
-<pre class="brush: python">if __name__ == '__main__':
-    TestContacts()</pre>
-
-<p>par :</p>
-
-<pre class="brush: python">if __name__ == '__main__':
-    unittest.main()</pre>
-
-<p>Ensuite, nous devons créer une méthode <code>setUp(self):</code> dans notre classe <code>TestContacts</code> et insérer les étapes suivantes :</p>
-
-<ol>
- <li>Instancier Marionette et démarrer une session Marionette</li>
- <li>Déverrouiller l'écran</li>
- <li>Tuer les applications ouvertes</li>
- <li>Charger l'application Contacts</li>
-</ol>
-
-<p>La méthode devrait ressembler au code ci-dessous. Vous devrez supprimer les lignes identiques qui sont déjà dans <code>test_add_contacts</code>.</p>
-
-<pre class="brush: python">    def setUp(self):
-         # Create the client for this session. Assuming you're using the default port on a Marionette instance running locally
-        self.marionette = Marionette()
-        self.marionette.start_session()
-
-        # Unlock the screen
-        self.unlock_screen()
-
-        # kill all open apps
-        self.kill_all()
-
-        # Switch context to the homescreen iframe
-        time.sleep(2)
-        home_frame = self.marionette.find_element('css selector', 'div.homescreen iframe')
-        self.marionette.switch_to_frame(home_frame)</pre>
-
-<p>Maintenant passons à la méthode <code>tearDown(self)</code>. A l'intérieur de celle-ci nous devons ajouter le code pour fermer la session Marionette. La méthode devrait ressembler à ceci :</p>
-
-<pre class="brush: python">    def tearDown(self):
-        # Close the Marionette session now that the test is finished
-        self.marionette.delete_session()
-</pre>
-
-<p>Encore une fois, n'oubliez pas de supprimer les lignes identiques dans <code>test_add_contacts</code>.</p>
-
-<p>Manitenant essayez d'exécuter le test exactement comme vous l'avez fait précédemment. Vous allez voir que vous obtenez un rapport de succès et d'échecs. Ceci est un des avantages d'utiliser un exécuteur de tests comme unittest ou py.test.</p>
-
-<div class="note">
-<p><strong>Note </strong>: Si vous êtes bloqués, il existe de nombreux guides d'utilisation de unittest sur Internet. Nous recommandons <a href="http://selenium-python.readthedocs.org/en/latest/getting-started.html">http://selenium-python.readthedocs.org/en/latest/getting-started.html</a> et <a href="http://assertselenium.com/2013/10/07/getting-started-with-python-webdriver/">http://assertselenium.com/2013/10/07/getting-started-with-python-webdriver/</a>. Ils sont pour Python et WebDriver mais sont tout de même appropriés.</p>
-</div>
-
-<h2 id="Code_de_référence">Code de référence</h2>
-
-<p>Pour référence, notre code final à cette étape ressemble à celui-ci :</p>
-
-<pre class="brush: python">import time
-from marionette import Marionette
-from marionette_driver import Wait
-import unittest
-
-
-class TestContacts(unittest.TestCase):
-
-    def unlock_screen(self):
-        self.marionette.execute_script('window.wrappedJSObject.lockScreen.unlock();')
-
-    def kill_all(self):
-        self.marionette.switch_to_frame()
-        self.marionette.execute_async_script("""
-             // Kills all running apps, except the homescreen.
-             function killAll() {
-               let manager = window.wrappedJSObject.AppWindowManager;
-
-               let apps = manager.getApps();
-               for (let id in apps) {
-                 let origin = apps[id].origin;
-                 if (origin.indexOf('verticalhome') == -1) {
-                   manager.kill(origin);
-                 }
-               }
-             };
-             killAll();
-             // return true so execute_async_script knows the script is complete
-             marionetteScriptFinished(true);
-            """)
-
-    def setUp(self):
-         # Create the client for this session. Assuming you're using the default port on a Marionette instance running locally
-        self.marionette = Marionette()
-        self.marionette.start_session()
-
-        # Unlock the screen
-        self.unlock_screen()
-
-        # kill all open apps
-        self.kill_all()
-
-        # Switch context to the homescreen iframe and tap on the contacts icon
-        time.sleep(2)
-        home_frame = self.marionette.find_element('css selector', 'div.homescreen iframe')
-        self.marionette.switch_to_frame(home_frame)
-
-
-    def test_add_contacts(self):
-        <code>contacts_icon = self.marionette.find_element('xpath', "</code><code>//div[@class='icon']//span[contains(text(),'Contacts')]")</code>
-        contacts_icon.tap()
-
-        # Switch context back to the base frame
-        self.marionette.switch_to_frame()
-        Wait(self.marionette).until(lambda m: m.find_element('css selector', "iframe[data-url*='contacts']").is_displayed())
-
-        # Switch context to the contacts app
-        contacts_frame = self.marionette.find_element('css selector', "iframe[data-url*='contacts']")
-        self.marionette.switch_to_frame(contacts_frame)
-
-        # Tap [+] to add a new Contact
-        self.marionette.find_element('id', 'add-contact-button').tap()
-        Wait(self.marionette).until(lambda m: m.find_element('id', 'save-button').location['y']== 0)
-
-        # Type name into the fields
-        self.marionette.find_element('id', 'givenName').send_keys('John')
-        self.marionette.find_element('id', 'familyName').send_keys('Doe')
-
-        # Tap done
-        self.marionette.find_element('id', 'save-button').tap()
-        Wait(self.marionette).until(lambda m: not m.find_element('id', 'save-button').is_displayed())
-
-    def tearDown(self):
-        # Close the Marionette session now that the test is finished
-        self.marionette.delete_session()
-
-if __name__ == '__main__':
-    unittest.main()
-
-</pre>
diff --git a/files/fr/archive/b2g_os/automated_testing/gaia-ui-tests/partie_6_marionette_classe_by/index.html b/files/fr/archive/b2g_os/automated_testing/gaia-ui-tests/partie_6_marionette_classe_by/index.html
deleted file mode 100644
index 85b1c5451b..0000000000
--- a/files/fr/archive/b2g_os/automated_testing/gaia-ui-tests/partie_6_marionette_classe_by/index.html
+++ /dev/null
@@ -1,77 +0,0 @@
----
-title: 'Partie 6: Utiliser des tuples, et la classe By de Marionette'
-slug: Archive/B2G_OS/Automated_testing/gaia-ui-tests/Partie_6_Marionette_classe_By
-tags:
-  - Automatisation
-  - B2G
-  - Firefox OS
-  - Gaia
-  - Marionette
-  - Python
-  - interface utilisateur
-  - tests
-translation_of: Archive/B2G_OS/Automated_testing/gaia-ui-tests/Part_6_Marionette_By_class
----
-<p> </p><div style="text-align: right;" class="prevnext">
-    <p><a style="float: left;" href="/fr/docs/Mozilla/Firefox_OS/Platform/Automated_testing/gaia-ui-tests/Part_5_Introducing_a_test_runner">« Précédent</a><a href="/fr/docs/Mozilla/Firefox_OS/Platform/Automated_testing/gaia-ui-tests/Part_7_Writing_your_own_tests">Suivant  »</a></p>
-</div><p></p>
-
-<div class="summary">
-<p><span class="seoSummary">Jusqu'à présent dans notre code, nous avons utilisé de nombreux repères pour trouver des éléments spécifiques, que ce soit des applications (iFrames) ou des parties d'applications. De plus, nous avons écrit les repères directement dans le code et en conséquence, dupliqué du code. Pour améliorer la situation par la suite, une bonne pratique est d'abstraire ces repères dans des variables tuples Python pour ensuite les réutiliser. Dans cet article, nous allons vous montrer comment faire.</span></p>
-</div>
-
-<h2 id="Les_tuples_et_la_classe_By_de_Marionette">Les tuples et la classe By de Marionette</h2>
-
-<p>Considérons comme exemple le repère que nous avons utilisé pour localiser le iFrame de l'application Contacts :</p>
-
-<pre class="brush: python">'css selector', "iframe[data-url*='contacts']"</pre>
-
-<p>Nous utilisons ce repère à la fois quand on attend l'affichage du cadre et quand on passe à l'intérieur de ce dernier. Pour rendre les choses plus simples, on peut stocker ceci dans une variable (il faut aussi iomporter <code>By</code>) :</p>
-
-<pre class="brush: python">from marionette import By
-
-_contacts_frame_locator = (By.CSS_SELECTOR, "iframe[data-url*='contacts']")</pre>
-
-<p>La classe <code>By</code> de Marionette fournit un court-circuit pour accéder aux techiques de repérage comme <code>id</code>, le sélecteur CSS... Comme précédemment, on saisit l'élément en utilisant le sélecteur et ensuite on le stocke dans une variable tuple CSS. Si l'HTML (et le repère) change, alors il est plus facile de simplement mettre à jour la variable une fois, plutôt que de réaliser les changements aux deux endroits. Pour utiliser ce tuple, il faut l'inclure dans la méthode <code>find_element()</code> comme suit :</p>
-
-<pre class="brush: python">self.marionette.find_element(*self._contacts_frame_locator)</pre>
-
-<div class="note">
-<p><strong>Note </strong>: <code>*</code> — dans ce contexte — est du code Python pour dépiler la liste d'arguments ; cela sépare le tuple d'origine en deux arguments que nous devons passer dans <code>find_element()</code>. Pour plus d'informations et d'exemples, lire <a href="http://docs.python.org/2/tutorial/controlflow.html#unpacking-argument-lists">Unpacking argument lists</a> dans la documentation Python.</p>
-</div>
-
-<p>Un autre exemple de tuple, qui repère via l'attribut <code>id</code> :</p>
-
-<pre class="brush: python">_add_contact_button_locator = (By.ID, 'add-contact-button')</pre>
-
-<h2 id="Utilisation_de_tuples_et_By_dans_notre_test_Contacts">Utilisation de tuples et By dans notre test Contacts</h2>
-
-<p>Maintenant il est temps de réduire la duplication dans notre cas de test <code>test_add_contact.py</code> en déplaçant les repères hors du test vers le périmètre de la classe <code>TestContacts</code> où ils peuvent être partagés. Nous allons vous montrer comment substituer un couple de repères et laisser le reste comme exercice pour le lecteur.</p>
-
-<p>D'abord vous devez vous assurer d'importer <code>By</code>, en mettant la ligne suivante au début de votre code :</p>
-
-<pre class="brush: python">from marionette import By</pre>
-
-<p>Maintenant nous pouvons ajouter nos tuples en haut de la classe <code>TestContacts</code> ; ajoutez les lignes suivantes juste en dessous de la ligne <code>class TestContacts(unittest.TestCase) </code>:</p>
-
-<pre class="brush: python">_contacts_frame_locator = (By.CSS_SELECTOR, "iframe[data-url*='contacts']")
-_save_button_locator = (By.ID, "save-button")
-</pre>
-
-<p>Désormais, vous pouvez parcourir votre code et remplacer toutes les instances de</p>
-
-<pre class="brush: python">find_element('id', 'save-button')</pre>
-
-<p>par</p>
-
-<pre class="brush: python">find_element(*self._save_button_locator)</pre>
-
-<p>et toutes les instances de</p>
-
-<pre class="brush: python">find_element('css selector', "iframe[data-url*='contacts']")</pre>
-
-<p>avec</p>
-
-<pre class="brush: python">find_element(*self._contacts_frame_locator)</pre>
-
-<p>Et c'est tout pour le moment. Nous sommes sûrs que vous allez déjà voir les bénéfices de cette réutilisation de code, même dans cet exemple simple. La technique commence à devenir particulièrement efficace dès que vous commencez à écrire des tests plus complexes qui peuvent utiliser le même repère 5, 10 ou 20 fois.</p>
diff --git a/files/fr/archive/b2g_os/automated_testing/gaia-ui-tests/partie_7_ecrire_vos_propres_tests/index.html b/files/fr/archive/b2g_os/automated_testing/gaia-ui-tests/partie_7_ecrire_vos_propres_tests/index.html
deleted file mode 100644
index 77a0cda65b..0000000000
--- a/files/fr/archive/b2g_os/automated_testing/gaia-ui-tests/partie_7_ecrire_vos_propres_tests/index.html
+++ /dev/null
@@ -1,63 +0,0 @@
----
-title: 'Partie 7 : Ecrire vos propres tests'
-slug: >-
-  Archive/B2G_OS/Automated_testing/gaia-ui-tests/Partie_7_Ecrire_vos_propres_tests
-tags:
-  - interface utilisateur
-translation_of: Archive/B2G_OS/Automated_testing/gaia-ui-tests/Part_7_Writing_your_own_tests
----
-<p></p><div style="text-align: right;" class="prevnext">
-    <p><a style="float: left;" href="/fr/docs/Mozilla/Firefox_OS/Platform/Automated_testing/gaia-ui-tests/Part_6_Marionette_By_class">« Précédent</a><a href="/fr/docs/Mozilla/Firefox_OS/Platform/Automated_testing/gaia-ui-tests/Part_8_Using_a_base_class">Suivant  »</a></p>
-</div><p></p>
-
-<div class="summary">
-<p><span class="seoSummary">Jusqu'à présent nous vous avons donné la plupart des outils et informations dont vous avez besoin pour commencer à écrire vos propres tests automatisés sur Firefox OS,  avec suffisamment d'étapes à suivre pour vous permettre de démarrer rapidement. Dans cette partie nous allons vous lâcher, en vous fournissant des ressources et idées, et ensuite en vous encourageant à faire votre propre chemin. Ici, nous allons vous pousser à écrire vos propres tests - profitez-en !</span></p>
-</div>
-
-<h2 id="Ressources">Ressources</h2>
-
-<p>Les ressources suivantes seront utiles quand vous commencerez à construire vos propres tests unitaires.</p>
-
-<ul>
- <li>Le <a href="/en-US/Firefox_OS/Using_the_App_Manager">gestionnaire d'applications Firefox OS</a> est un formidable outil pour déboguer Gaia directement sur l'appareil ou sur un simulateur. C'est une bonne manière d'inspecter le code sous-jacent pour trouver quels repères utiliser pour accéder et manipuler des éléments.</li>
- <li>Comme mécanisme de contrôle général plus limité mais plus fiable, vous pouvez aussi déposer la source HTML dans la console en utilisant la commande <code>print self.marionette.page_source</code>.</li>
- <li>Une autre option est de regarder le HTML brut dans le <a href="https://github.com/mozilla-b2g/gaia/tree/master/apps">dépôt Git de Gaia</a>.</li>
- <li>Pour en savoir plus sur les commandes Marionette, lisez les <a href="https://marionette_client.readthedocs.org/en/latest/">documents Marionette</a>.</li>
-</ul>
-
-<h2 id="Idées_pour_des_nouveaux_tests_et_des_modifications_de_tests">Idées pour des nouveaux tests et des modifications de tests</h2>
-
-<p>Cette section vous fournir un peu d'idées pour vous lancer.</p>
-
-<h3 id="Modifier_test_add_contact.py">Modifier test_add_contact.py</h3>
-
-<p>Commençons par modifier le test sur lequel nous avons déjà travaillé :</p>
-
-<ol>
- <li>Faire que le contact testé ait un nom unique à chaque fois.</li>
- <li>Supprimer tous les contacts dans l'étape <code>setUp()</code>.</li>
- <li>Réveiller l'écran avant le déverrouillage.</li>
-</ol>
-
-<p>Maintenant ajoutons une nouvelle méthode de test. Vous pouvez l'appeler comme vous le souhaitez du moment qu'elle commence par <code>test_</code>. Ce test réalise les choses suivantes :</p>
-
-<ol>
- <li>Ouvrez Contacts.</li>
- <li>Créez un contact avec un nom différent de celui créé dans le premier test.</li>
- <li>Entrez de nouveau dans le mode édition du contact.</li>
- <li>Ajoutez une <em>Société</em>.</li>
- <li>Appuyez sur <em>OK</em>.</li>
- <li>Vérifiez que l'entreprise est listée.</li>
-</ol>
-
-<p>Maintenant quand vous exécutez le fichier test, les deux tests vont s'exécuter. Nous nous rapprochons de la force de l'automatisation de tests - la capacité d'exécuter une série de tests de manière automatique et de remonter les résultats !</p>
-
-<h3 id="D'autres_idées_nouvelles_de_tests">D'autres idées nouvelles de tests</h3>
-
-<ul>
- <li>Créer un contact, éditer le contact et changer le nom. Le changement de nom devrait apparaitre sur l'écran.</li>
- <li>Créer un contact et appuyer sur l'étoile pour l'ajouter dans les favoris. Sur l'écran principal il devrait s'afficher sous la catégorie des favoris.</li>
- <li>Créer un contact avec un numéro de téléphone. Après avoir ouvert le répertoire de contacts et appuyé sur l'icône Message, l'application messages devrait s'ouvrir avec le contact dans le champ des destinataires.</li>
-</ul>
-
-<p> </p>
diff --git a/files/fr/archive/b2g_os/automated_testing/gaia-ui-tests/partie_8_utiliser_une_classe_base/index.html b/files/fr/archive/b2g_os/automated_testing/gaia-ui-tests/partie_8_utiliser_une_classe_base/index.html
deleted file mode 100644
index 6529777ae6..0000000000
--- a/files/fr/archive/b2g_os/automated_testing/gaia-ui-tests/partie_8_utiliser_une_classe_base/index.html
+++ /dev/null
@@ -1,94 +0,0 @@
----
-title: 'Partie 8 : Utiliser une classe base'
-slug: >-
-  Archive/B2G_OS/Automated_testing/gaia-ui-tests/Partie_8_Utiliser_une_classe_base
-tags:
-  - Automatisation
-translation_of: Archive/B2G_OS/Automated_testing/gaia-ui-tests/Part_8_Using_a_base_class
----
-<p></p><div style="text-align: right;" class="prevnext">
-    <p><a style="float: left;" href="/fr/docs/Mozilla/Firefox_OS/Platform/Automated_testing/gaia-ui-tests/Part_7_Writing_your_own_tests">« Précédent</a><a href="/fr/docs/Mozilla/Firefox_OS/Platform/Automated_testing/gaia-ui-tests/Part_9_app_objects">Suivant  »</a></p>
-</div><p></p>
-
-<div class="summary">
-<p><span class="seoSummary">À présent vous avez des tests multiples et vous sentez probablement que vous avez bien progressé. Pourtant, il existe d'autres manières d'améliorer encore l'efficacité de votre code — vous pouvez remarquer que vous avez dû jusqu'ici inclure les méthodes <code>setUp()</code> et <code>tearDown()</code> dans chaque fichier de test, au fur et à mesure de notre progression. Si vous avez plusieurs douzaines de tests alors il y a beaucoup de duplication de code ! Dans cet article, nous allons regarder comment mettre le code <code>setUp()</code>/<code>tearDown()</code> commun à tous les tests dans une classe <code>TestBase</code>, qui peut ainsi être importée dans chaque fichier de test.</span></p>
-</div>
-
-<h2 id="test_base.py">test_base.py</h2>
-
-<p>Pour commencer, créez un nouveau fichier nommé <code>test_base.py</code>, dans le même dossier que vos cas de tests existants.</p>
-
-<p>Ensuite, déplacez vos déclarations relatives à la configuration commune (<code>unittest</code>, <code>Marionette</code> et <code>time</code>) dans le fichier, avec une classe <code>TestBase</code> contenant les méthodes <code>setUp()</code> et <code>tearDown()</code>, et les fonctions d'aide communes (comme <code>unlock_screen()</code>). Le fichier devrait ressembler à cela :</p>
-
-<pre class="brush: python">import time
-import unittest
-from marionette import Marionette
-
-
-class TestBase(unittest.TestCase):
-
-    def unlock_screen(self):
-        self.marionette.execute_script('window.wrappedJSObject.lockScreen.unlock();')
-
-    def kill_all(self):
-        self.marionette.switch_to_frame()
-        self.marionette.execute_async_script("""
-             // Kills all running apps, except the homescreen.
-             function killAll() {
-               let manager = window.wrappedJSObject.AppWindowManager;
-
-               let apps = manager.getApps();
-               for (let id in apps) {
-                 let origin = apps[id].origin;
-                 if (origin.indexOf('verticalhome') == -1) {
-                   manager.kill(origin);
-                 }
-               }
-             };
-             killAll();
-             // return true so execute_async_script knows the script is complete
-             marionetteScriptFinished(true);
-            """)
-
-    def setUp(self):
-         # Create the client for this session. Assuming you're using the default port on a Marionette instance running locally
-        self.marionette = Marionette()
-        self.marionette.start_session()
-
-        # Unlock the screen
-        self.unlock_screen()
-
-        # kill all open apps
-        self.kill_all()
-
-        # Switch context to the homescreen iframe and tap on the contacts icon
-        time.sleep(2)
-        home_frame = self.marionette.find_element('css selector', 'div.homescreen iframe')
-        self.marionette.switch_to_frame(home_frame)
-
-
-    def tearDown(self):
-        # Close the Marionette session now that the test is finished
-        self.marionette.delete_session()
-</pre>
-
-<h2 id="Mettre_à_jour_vos_fichiers_de_test">Mettre à jour vos fichiers de test</h2>
-
-<p>Avec la création de votre fichier <code>test_base.py</code>, vous devez importer <code>TestBase</code> dans vos fichiers de test, et les classes de test doivent être changées pour étendre la classe <code>TestBase</code> :</p>
-
-<pre class="brush: python">import unittest
-from marionette import Wait
-from marionette import By
-from test_base import TestBase
-
-class TestContacts(TestBase):
-
-    def test(self):
-        # Tests in here
-
-if __name__ == '__main__':
-    unittest.main()</pre>
-
-<p>Essayez d'exécuter votre fichier de test de nouveau.</p>
-
-<p>Vous ne devriez pas voir de grande différence maintenant mais si vous avez des douzaines ou des centaines de tests, cela économise beaucoup de code dupliqué.</p>
diff --git a/files/fr/archive/b2g_os/automated_testing/gaia-ui-tests/partie_9_objets_app/index.html b/files/fr/archive/b2g_os/automated_testing/gaia-ui-tests/partie_9_objets_app/index.html
deleted file mode 100644
index aecb44aec1..0000000000
--- a/files/fr/archive/b2g_os/automated_testing/gaia-ui-tests/partie_9_objets_app/index.html
+++ /dev/null
@@ -1,80 +0,0 @@
----
-title: 'Partie 9 : Réduire le code dupliqué avec des objets app'
-slug: Archive/B2G_OS/Automated_testing/gaia-ui-tests/Partie_9_objets_app
-tags:
-  - Automatisation
-translation_of: Archive/B2G_OS/Automated_testing/gaia-ui-tests/Part_9_app_objects
----
-<p></p><div style="text-align: right;" class="prevnext">
-    <p><a style="float: left;" href="/fr/docs/Mozilla/Firefox_OS/Platform/Automated_testing/gaia-ui-tests/Part_8_Using_a_base_class">« Précédent</a><br></p>
-</div><p></p>
-
-<div class="summary">
-<p><span class="seoSummary">Dans l'automatisation de tests nous utilisons souvent les objets app pour abstraire le code. Cela réduit la duplication de code et de repères. Si nous avons besoin de changer une section de code commune, nous pouvons la changer juste dans un seul objet <code>app</code>, plutôt que d'avoir à la modifier dans 10 ou 20 fichiers de test. Cet article donne les bases de l'utilisation des objets <code>app</code>.</span></p>
-</div>
-
-<h2 id="Objets_app_bien_démarrer">Objets app : bien démarrer</h2>
-
-<p>L'objet <code>app</code> est une classe Python qui contient des méthodes et des propriétés qui représentent les actions sur une page. Regardons comment nous pouvons utiliser ceci dans un exemple théorique.</p>
-
-<h3 id="homepage.py">homepage.py</h3>
-
-<p>Voici un cadre que nous pouvons utiliser pour l'app Homepage avec un peu de pseudo-code.</p>
-
-<pre class="brush: python">class Homepage:
-        __init__(self, marionette):
-                # Marionette is passed in so that the object can use it
-                self.marionette = marionette
-
-        def switch_to_homepage_frame(self):
-                # Code for switching to System then to Homepage frame
-
-        def tap_contacts_icon(self):
-                # Code to tap the icon
-                # Switch to Contacts frame
-                # Now we return the Contacts app object as it has focus
-                from contacts import Contacts
-                return Contacts(self.marionette)</pre>
-
-<h3 id="contacts.py">contacts.py</h3>
-
-<p>Et voici ce que nous pouvons utiliser pour l'app Contacts, avec encore du pseudo-code.</p>
-
-<pre class="brush: python">class Contacts:
-        _new_contact_button = (By.ID, ‘id’)
-
-        def tap_new_contact(self):
-                # Tap new contact icon
-                # Wait for event
-
-        def type_given_name(self, name_string):
-                # element.send_keys(name_string)</pre>
-
-<h3 id="test_contacts.py"><strong>test_contacts.py</strong></h3>
-
-<p>Pour comprendre comment cela fonctionne dans le contexte d'un test, voici un exemple rapide qui utilise la classe <code>Homepage</code> :</p>
-
-<pre class="brush: python">from homepage import Homepage
-
-def test_add_contact(self):
-        homepage = Homepage(self.marionette)
-        homepage.switch_to_homepage_frame()
-
-contacts = homepage.tap_contacts_icon()
-contacts.tap_new_contact()</pre>
-
-<h2 id="Mettre_à_jour_vos_tests">Mettre à jour vos tests</h2>
-
-<p>À partir de cela, nous voudrions vous pousser à mettre à jour tous vos fichiers de test pour utiliser le nouveau système d'objets app.</p>
-
-<p>C'est une tâche difficile si vous n'êtes pas familier avec les structures de classes Python, vous aurez peut-être besoin de consulter quelques livres pour avoir des références et des exemples de code.</p>
-
-<p>Quand vous aurez fini, idéalement vous aurez une séparation claire entre les fichiers de test :</p>
-
-<ol>
- <li><code>TestBase</code> contiendra les méthodes <code>setUp()</code> et <code>tearDown()</code></li>
- <li>Les objets <code>app</code> contiendront les interactions et repères des pages</li>
- <li>Vos fichiers de test contiendront uniquement les étapes de test.</li>
-</ol>
-
-<p>Bonne chance !</p>
diff --git a/files/fr/archive/b2g_os/automated_testing/index.html b/files/fr/archive/b2g_os/automated_testing/index.html
deleted file mode 100644
index 5ec736aa4d..0000000000
--- a/files/fr/archive/b2g_os/automated_testing/index.html
+++ /dev/null
@@ -1,93 +0,0 @@
----
-title: Test automatisé pour Firefox OS
-slug: Archive/B2G_OS/Automated_testing
-translation_of: Archive/B2G_OS/Automated_testing
----
-<p></p>
-
-<div class="summary">
-<p>Vu que Firefox OS est en cours de développement, et que le support pour le nouveau matériel est à venir dans un futur proche, il est important de savoir comment le tester. Cette page présente des articles qui fournissent des informations concernant différents aspects pour le test de Firefox OS, ainsi que l’exécution des tests, l’automatisation, le suivi et l'établissemenr de rapports des résultats.</p>
-</div>
-
-<h2 id="Premiers_pas">Premiers pas</h2>
-
-<dl>
- <dt><a href="/fr/Firefox_OS/Running_Tests_on_Firefox_OS_for_Developers">Exécuter des tests sur Firefox OS: un guide pour les développeurs</a></dt>
- <dd>
- <p>Un guide rapide, pour les développeurs, pour commencer à exécuter les tests. C’est d’ici que vous devez commencer si vous n’êtes pas confirmés dans l’exécution des tests Mozilla et les systèmes d’automatisation. Si vous l’êtes, vous aurez probablement une idée sur les tests que vous devez exécuter et comment procéder, et vous pouvez aller directement aux guides plus détaillées ci-dessous. </p>
- </dd>
-</dl>
-
-<h2 id="Les_tests_Gaia">Les tests Gaia</h2>
-
-<p>Ces articles couvrent les suites de test primaires destinées à mettre Gaia à l’épreuve.</p>
-
-<dl>
- <dt><a href="/fr/Firefox_OS/Automated_testing/gaia-ui-tests">Tests d'interface utilisateur Gaia</a></dt>
- <dd>Tests Python des interactions et caractéristiques de l’interface utilisateur Gaia.</dd>
- <dt><a href="/en-US/docs/Mozilla/Firefox_OS/Platform/Automated_testing/Gaia_integration_tests">Tests d'intégration Gaia</a></dt>
- <dd>Tests d’intégration JavaScript pour Gaia, basés sur Marionette.</dd>
- <dt><a href="/en-US/docs/Mozilla/Firefox_OS/Platform/Automated_testing/Gaia_unit_tests" title="/en-US/docs/Mozilla/Firefox_OS/Platform/Testing/Gaia_unit_tests">Tests unitaires Gaia</a></dt>
- <dd>Tests unitaires sans interaction avec l'interface utilisateur; écrits en JavaScript, et non basés sur Mrionette.</dd>
- <dt><a href="/en-US/Firefox_OS/Platform/Automated_testing/Gaia_performance_tests">Tests de performance Gaia</a></dt>
- <dd>Mesure des performance de l'application Gaia en se basant sur une instrumentation interne. The testing harness is in-tree.</dd>
- <dt><a href="/en-US/Firefox_OS/Automated_testing/Raptor">Raptor: Outils de mesure de performance pour Gaia</a></dt>
- <dd>Raptor est un outil qui permet de mesurer la performance spécifique à Firefox OS, qui à pour ambition d'améliorer les outils de test de performance existants.</dd>
- <dt><a href="https://github.com/mozilla/b2gperf" title="https://github.com/mozilla/b2gperf">B2GPerf</a></dt>
- <dd>Mesure la performance d'applications Gaia, basé sur une cuisine interne.</dd>
- <dt><a href="https://wiki.mozilla.org/Project_Eideticker" title="https://github.com/mozilla/eideticker">Eideticker</a></dt>
- <dd>Donne des mesures de performance d'applications Gaia, en se basant sur des captures d'écran.</dd>
- <dt><a href="/en-US/docs/Mozilla/Firefox_OS/Automated_testing/MTBF_tests">Tests MTBF</a></dt>
- <dd>Durée moyenne avant panne(Mean Time Between Failure). Suite de tests lancés sur un périphérique pendant une longue période, essayant de trouver des problèmes de disponibilité de Gaia et de stabilité. (Actuellement, il est dans les mains de l'équipe Qualité à Taiwan et reste un framework de test en développement)</dd>
-</dl>
-
-<h2 id="Les_tests_B2G">Les tests B2G</h2>
-
-<p>Les tests ci-dessous couvrent différents faisceaux d'essai qui permettent de tester de nombreux aspect et fonctionnalités de B2G.</p>
-
-<dl>
- <dt><a href="/en-US/docs/Mozilla/Firefox_OS/Platform/Automated_testing/Mochitests" title="/en-US/docs/Mozilla/Firefox_OS/Platform/Testing/Mochitests">Mochitests</a></dt>
- <dd>Tests fonctionnels et d'API, basés sur HTML et JavaScript. Les tests n'interagissent pas avec Gaia.</dd>
- <dt><a href="/en-US/docs/Mozilla/Firefox_OS/Platform/Automated_testing/Reftests" title="/en-US/docs/Mozilla/Firefox_OS/Platform/Testing/Reftests">Reftests</a></dt>
- <dd>Test d'exactitude des rendus des tests Gecko.</dd>
- <dt><a href="/en-US/docs/Marionette/Marionette_JavaScript_Tests" title="/en-US/docs/Marionette/Marionette_JavaScript_Tests">WebAPI tests</a></dt>
- <dd>Tests des WebAPI Gecko, en se basant sur JavaScript. La majorité de ces tests exigent un émulateur.</dd>
- <dt><a href="/en-US/docs/Mozilla/Firefox_OS/Platform/Automated_testing/XPCShell" title="/en-US/docs/Mozilla/Firefox_OS/Platform/Testing/XPCShell">xpcshell tests</a></dt>
- <dd>Tests 'sans tête' (headless) des API XPCOM de Gecko.</dd>
- <dt><a href="/en-US/docs/Mozilla/Firefox_OS/Automated_testing/Cppunit_Tests">Tests cppunit</a></dt>
- <dd>Tests unitaires C++ 'sans tête' (headless).</dd>
-</dl>
-
-<h2 id="Supporting_documentation">Supporting documentation</h2>
-
-<p>Cette section, apporte des liens, sur quelques-unes des technologies de support, sur lesquels les tests Mozilla s'appuient, et pour lesquels vous voudrez surement en savoir plus.</p>
-
-<dl>
- <dt><a href="/en-US/docs/Marionette" title="/en-US/docs/Marionette">Marionette</a></dt>
- <dd>Un conducteur de test à distance, basé sur Selenium.</dd>
- <dt><a href="/en-US/docs/Marionette/Marionette_JavaScript_Tools">Outils JavaScript Marionette</a></dt>
- <dd>Basés sur node.js ils permettent de lancer des tests sur Marionette.</dd>
- <dt><a href="/en-US/docs/Marionette/Python_Marionette">Client Python Marionette</a></dt>
- <dd>Un client Python pour lancer des tests sur Marionette.</dd>
- <dt><a href="https://wiki.mozilla.org/Build:TryServer">Try server</a></dt>
- <dd>Serveur de Mozilla permettant de tester les correctifs avant de les intégrer dans le répertoire central. Voir aussi le <a href="http://trychooser.pub.build.mozilla.org/">TryChooser Syntax Builder</a>.</dd>
-</dl>
-
-<div class="note">
-<p><strong>A noter</strong>: Si vous souhaitez lancer Marionette sur une compilation pour la production (pour lancer les tests d'intégration de gaia, gaia-ui-tests, etc.), vous pouvez <a href="https://github.com/mozilla-b2g/marionette-extension">installer Marionette comme une extension</a> (cela fonctionne pour l'instant uniquement sur les compilations en version 1.3, mais le support sera bientôt plus étendu.)</p>
-</div>
-
-<h2 id="Intégration_continue_et_rapport_des_résultats">Intégration continue et rapport des résultats</h2>
-
-<p>Les articles suivants couvrent les mécanismes d'intégration continue et d'établissement de rapports des résultats utilisés par Mozilla afin de sauvegarder et interpréter les données de test.</p>
-
-<dl>
- <dt><a href="/en-US/docs/Mozilla/Firefox_OS/Automated_testing/Treeherder">Treeherder</a></dt>
- <dd>Comprendre les tests et compilations lancées sur Treeherder.</dd>
- <dt><a href="http://raptor-ui.divshot.io">Raptor</a></dt>
- <dd>Visualisation des tests de performance lancés avec l'outil <a href="/en-US/Firefox_OS/Automated_testing/Raptor">Raptor</a>.</dd>
- <dt><a href="https://wiki.mozilla.org/B2G/Datazilla" title="https://wiki.mozilla.org/B2G/Datazilla">Datazilla [déprécié]</a></dt>
- <dd>Comprendre quels tests de performances sont rapportés sur <a href="https://datazilla.mozilla.org/b2g/" title="https://datazilla.mozilla.org/b2g/">Tableau de bord Datazilla</a>, et qu'est ce qu'ils mesurent.</dd>
- <dt><a href="/en-US/docs/Mozilla/Firefox_OS/Platform/Automated_testing/Test_Execution_Chart" title="/en-US/docs/Mozilla/Firefox_OS/Testing/Test_Execution_Chart">Graphe de test d'exécution</a></dt>
- <dd>Un graphe montrant quels tests ont été exécutés - sur quels appareils et quand - et quelles sont les plateformes supportées par chaque test.</dd>
-</dl>
diff --git a/files/fr/archive/b2g_os/automated_testing/marionette_pour_python_interactif/index.html b/files/fr/archive/b2g_os/automated_testing/marionette_pour_python_interactif/index.html
deleted file mode 100644
index 729263087f..0000000000
--- a/files/fr/archive/b2g_os/automated_testing/marionette_pour_python_interactif/index.html
+++ /dev/null
@@ -1,75 +0,0 @@
----
-title: Marionette pour du Pyhton interactif
-slug: Archive/B2G_OS/Automated_testing/Marionette_pour_Python_interactif
-translation_of: Archive/B2G_OS/Automated_testing/Marionette_for_interactive_Python
----
-<p>Ce tutoriel suppose que vous avez <a href="/en-US/docs/Mozilla/Firefox_OS/Platform/Testing/Setting_up_Marionette" title="https://developer.mozilla.org/en/Mozilla/Boot_to_Gecko/Setting_Up_Marionette_for_B2G">configuré Marionette pour B2G</a>.</p>
-
-<p>Ouvrez un terminal et lancez Python pour obtenir l'invite interactive :</p>
-
-<p><code>$ python</code></p>
-
-<p>Depuis l'invite interactive, exécutez les commandes nécessaire pour invoquer une session Marionette de manière interactive :</p>
-
-<p><span style='font-family: "Courier New",Courier,monospace;'>&gt;&gt;&gt; from marionette import Marionette<br>
- &gt;&gt;&gt; marionette = Marionette('localhost', 2828)<br>
- &gt;&gt;&gt; marionette.start_session()<br>
-  u'session-b2g'</span></p>
-
-<p>Ici, nous voyons que le système renvoie qu'une session Marionette est en cours d'exécution.</p>
-
-<p><a class="external" href="http://4.bp.blogspot.com/-wdjTWI_UrH0/Tys1t-VWTMI/AAAAAAAAANM/Hb3pLdPOoMc/s640/Starting+Marionette+Session+Interactively.tiff"><img alt="" class="default" src="http://4.bp.blogspot.com/-wdjTWI_UrH0/Tys1t-VWTMI/AAAAAAAAANM/Hb3pLdPOoMc/s640/Starting+Marionette+Session+Interactively.tiff"></a></p>
-
-<p>La commande "<code>marionette.execute_script()</code>" peut intégrer des commandes JavaScript, qui peuvent ensuite s'exécuter sur une plateforme B2G. En utilisant ceci, nous pouvons voir quels éléments DOM renvoient des objets HTMLElement ainsi que les attributs et méthodes disponibles :</p>
-
-<p><span style='font-family: "Courier New",Courier,monospace;'>&gt;&gt;&gt; marionette.execute_script("return navigator.battery;")<br>
- {u'onlevelchange': None, u'level': 0.91, u'dischargingTime': None, u'onchargingchange': None, u'ondischargingtimechange': None, u'onchargingtimechange': None, u'chargingTime': None, u'charging': True}<br>
- &gt;&gt;&gt; marionette.execute_script("return navigator.battery.level;")<br>
- 0.91<br>
- &gt;&gt;&gt; marionette.execute_script("return navigator.geolocation;")<br>
- {}<br>
- &gt;&gt;&gt; marionette.execute_script("return navigator.mozSms;")<br>
- {u'onreceived': None, u'ondelivered': None, u'onsent': None}</span></p>
-
-<p><a class="external" href="http://2.bp.blogspot.com/-WaSbVYa85K0/Tys2-IJC3ZI/AAAAAAAAANU/s7wvpanwmNY/s640/Getting+DOMHTMLelements.tiff"><img alt="" class="default" src="http://2.bp.blogspot.com/-WaSbVYa85K0/Tys2-IJC3ZI/AAAAAAAAANU/s7wvpanwmNY/s640/Getting+DOMHTMLelements.tiff"></a></p>
-
-<p>Vous pouvez parcourir l'arbre DOM en utilisant cette technique pour évaluer quels objets, méthode et attributs sont disponibles.</p>
-
-<h2 id="Tester_la_téléphonie_basique_de_manière_interactive">Tester la téléphonie basique de manière interactive</h2>
-
-<p>Vous pouvez tester de manière interactive la téléphonie de base avec Marionette.  L'exemple suivant nécessite deux téléphones en état de fonctionnement, chacun ayant sa carte sim. L'un d'eux est notre Galaxy SII, avec B2G en cours d'exécution.</p>
-
-<p>Lancez une session Marionette interactive  et transférez le port :</p>
-
-<p><code>$ adb forward tcp:2828 tcp:2828<br>
- $ python<br>
- &gt;&gt;&gt; from marionette import Marionette<br>
- &gt;&gt;&gt; marionette = Marionette('localhost', 2828)<br>
- &gt;&gt;&gt; marionette.start_session()<br>
- u'5-b2g</code></p>
-
-<p>À présent, deux approches sont possibles avec Marionette.  L'une d'elles est un peu plus<em> Pythonesque </em>:</p>
-
-<p><code>&gt;&gt;&gt; marionette.set_context("chrome")<br>
- True<br>
- &gt;&gt;&gt; marionette.execute_script("return navigator.mozTelephony;")<br>
- &gt;&gt;&gt; num =<br>
- &gt;&gt;&gt; marionette.execute_script("return navigator.mozTelephony.dial('%d');" % num)</code></p>
-
-<p>Ou la seconde approche qui repose plus sur du JS (embarqué dans <code>marionette.execute_script()</code> ) Remarquez les guillemets autour de la variable JS nombre :</p>
-
-<p><code>&gt;&gt;&gt; marionette.set_context("chrome")<br>
- True<br>
- &gt;&gt;&gt; marionette.execute_script("""<br>
- ... var num = ""<br>
- ... return navigator.mozTelephony.dial(num);<br>
- ... """)<br>
- {} </code></p>
-
-<p>Nous allons essayer la première approche :</p>
-
-<p><a class="external" href="http://3.bp.blogspot.com/-cAsP3Beif4g/Tyxr92r6baI/AAAAAAAAANk/GiMlZsXfFYc/s640/Marionette_interactive_telephony.tiff"><img alt="" class="default" src="http://3.bp.blogspot.com/-cAsP3Beif4g/Tyxr92r6baI/AAAAAAAAANk/GiMlZsXfFYc/s640/Marionette_interactive_telephony.tiff"></a></p>
-
-<p>Ceci démarre un appel téléphonique, dont la sortie peut être contrôlée dans <code>$adb logcat</code></p>
-
-<p><a class="external" href="http://4.bp.blogspot.com/-Np12ZkqpRfM/Tyxs3zAf0EI/AAAAAAAAANs/xhr58eU_s00/s640/ADB+LOGCAT+interactive+telephony.tiff"><img alt="" class="default" src="http://4.bp.blogspot.com/-Np12ZkqpRfM/Tyxs3zAf0EI/AAAAAAAAANs/xhr58eU_s00/s640/ADB+LOGCAT+interactive+telephony.tiff"></a></p>
diff --git a/files/fr/archive/b2g_os/automated_testing/mtbf_tests/index.html b/files/fr/archive/b2g_os/automated_testing/mtbf_tests/index.html
deleted file mode 100644
index 8f624687ac..0000000000
--- a/files/fr/archive/b2g_os/automated_testing/mtbf_tests/index.html
+++ /dev/null
@@ -1,233 +0,0 @@
----
-title: MTBF tests
-slug: Archive/B2G_OS/Automated_testing/MTBF_tests
-translation_of: Archive/B2G_OS/Automated_testing/MTBF_tests
----
-<div class="summary">
-<p>Les essais de MTBF sont une suite de tests de Firefox OS construits au-dessus du framework  <a href="https://developer.mozilla.org/en-US/Firefox_OS/Automated_testing/gaia-ui-tests">Gaiatest (Tests IU Gaia)</a> . Les tests effectués sur de vrais dispositifs de Firefox OS, et utilisent <a href="https://developer.mozilla.org/en-US/docs/Mozilla/QA/Marionette">Marionette </a>pour conduire l'interface utilisateur de l'appareil. Ces tests sont conçus pour mesurer la stabilité / fiabilité de l'application, et de remplacer <a href="https://developer.mozilla.org/en-US/Firefox_OS/Automated_testing/Endurance">les tests d'endurance Gaia</a> maintenant abandonnées.</p>
-</div>
-
-<p><strong>Mean time between failures (MTBF)</strong> is the predicted elapsed time between inherent failures of a system during operation. MTBF can be calculated as the arithmetic mean (average) time between failures of a system. The MTBF is typically part of a model that assumes the failed system is immediately repaired (mean time to repair, or MTTR), as a part of a renewal process. This is in contrast to the mean time to failure (MTTF), which measures average time to failures with the modeling assumption that the failed system is not repaired (infinite repair time).</p>
-
-<h2 id="Current_Environment_Setup">Current Environment &amp; Setup</h2>
-
-<p>MTBF tests are run by automation; the test suite collects general test cases like send sms, email, set alarm, etc., and executes them to emulate typical user behavior.  Right now we have more than 10 Firefox OS phones concurrently running tests in our test lab.</p>
-
-<h3 id="How_often_are_the_tests_run">How often are the tests run?</h3>
-
-<p>MTBF is purposed to test on versions or branches with 0 functional failures.  it runs when everything passes in our smoke tests; the testing code should be in the Aurora (next release) branch.</p>
-
-<h3 id="Where_can_I_see_the_results">Where can I see the results?</h3>
-
-<p>MTBF is still being developed and you can mail us for an early report (try the <a href="https://lists.mozilla.org/listinfo/dev-b2g">dev-b2g</a> or <a href="https://lists.mozilla.org/listinfo/dev-gaia">dev-gaia</a> mailing lists).  You can set up the necessary environment to run the tests yourself and generate your own reports by following the below steps.</p>
-
-<h2 id="Running_the_tests">Running the tests</h2>
-
-<p>Let's go through the steps required to set up the Gaia-UI MTBF test environment and run the tests on your local machine and Firefox OS device.</p>
-
-<h3 id="Prerequisites">Prerequisites</h3>
-
-<ul>
- <li>Ubuntu 12.04 (or better) x64 or Mac OS X (these instructions are confirmed for 10.8 but should work on previous versions of 10, theoretically.)</li>
- <li>A Firefox OS device ALREADY FLASHED with an ENGINEERING build of Firefox OS B2G-18 V1-Train (1.1.)</li>
- <li><a href="/en-US/Firefox_OS/Debugging/Installing_ADB">ADB installed</a>, and the environment variable <code>ADB_PATH</code> pointing to your ADB location.</li>
-</ul>
-
-<p>If you are on Ubuntu, you need to check that it is configured to support the USB connection to the Firefox OS device. To verify this, connect the device to your computer via USB, open a terminal and enter the <code>adb logcat</code> command to see if it connects. If not, you may need to set up a <a href="/en-US/Firefox_OS/Firefox_OS_build_prerequisites#For_Linux.3A_configure_the_udev_rule_for_your_phone">udev rule</a> for the device.</p>
-
-<div class="note">
-<p><strong>Note</strong>: At the point where you start running through the following steps, the Firefox OS device should not be connected to your computer. You will be told when to connect it in the steps below.</p>
-</div>
-
-<h3 id="Step_1_Clone_the_MTBF-Driver_repository_from_Mozilla-TWQA">Step 1: Clone the MTBF-Driver repository from Mozilla-TWQA</h3>
-
-<p>The Gaia-UI MTBF Tests are located in the Mozilla Github Gaia repository. Assuming that you haven’t done so already, the first step is to clone that repo:</p>
-
-<pre class="brush: bash">git clone https://github.com/Mozilla-TWQA/MTBF-Driver.git</pre>
-
-<p>You may want to go get a coffee and come back in five minutes. Furthermore, you can get all the branches and try to switch to the current MTBF branch (e.g. master or v1.4+.) In this case, master matches the current master branch Gaia, and v1.4+ matches the v1.4/v1.3 branch Gaia.</p>
-
-<h3 id="Step_2_Run_the_GaiaTest_setup">Step 2: Run the GaiaTest setup</h3>
-
-<p>The Gaia-UI MTBF tests are built upon the GaiaTest framework (which uses <a href="https://developer.mozilla.org/en-US/docs/Marionette" title="Marionette">Marionette</a>). The next step is to run the setup script to install GaiaTest and all of the required dependencies. You may wish to create a new virtual environment to use with the Gaia-UI MTBF Tests. If you don’t, you may need to use <code>sudo</code> while running the setup command. In your terminal, type:</p>
-
-<pre class="brush: bash">cd MTBF-Driver
-python setup.py develop</pre>
-
-<h3 id="Step_3_Get_memory_tools_if_you_need_them">Step 3: Get memory tools if you need them</h3>
-
-<p>To access the memory tools, find them in the <code>tools</code> directory in the <code>B2G</code> repo. If you've not already got this, clone it from Github like so (this is also a large download):</p>
-
-<pre class="brush: bash">git clone https://github.com/mozilla-b2g/B2G.git</pre>
-
-<p>You should copy the tools folder into the <code>MTBF-Driver/mtbf_drivers</code> directory.</p>
-
-<h3 id="Step_4_Set_test_vars_and_acknowledge_risks">Step 4: Set test vars and acknowledge risks</h3>
-
-<p>GaiaTest uses a special file to set certain variables that are required for test configuration, for example to tell the device which WiFi network it should use. Before running the Gaia-UI MTBF Tests, you must set up the test vars file. Make a copy of the <code>gaia/tests/python/gaia-ui-tests/gaiatest/testvars_template.json</code> file in its existing location (rename it to something memorable) and edit it:</p>
-
-<ul>
- <li>If the Firefox OS device has a SIM card, add the corresponding phone number in the phone number field in the <code>carrier</code> section, e.g. <code>"phone_number": "5551234567"</code>.</li>
- <li>Add the same phone number inside the <code>"remote_phone_number"</code> field.</li>
- <li>In the <code>wifi</code> section, add the SSID for the Wifi network that the Firefox OS device is to connect to during the tests in the <code>ssid</code> field, for example <code>"ssid": "Wifi Network Name"</code>.</li>
-</ul>
-
-<p>Running the Gaia-UI MTBF tests will result in data being erased from the Firefox OS device and microSD card. This is to ensure that the tests start cleanly each time. For example, running a contacts test on a device that already has 10,000 contacts will have very different memory value results compared to running the same test on a device with no existing contacts. In order to run the tests, you must acknowledge that you are aware of this data loss risk. You should also <a href="/en-US/Firefox_OS/Developing_Gaia/Gaia_tools_reference#Backup_and_restore_profile">backup any data</a> you don't want to lose.</p>
-
-<p>To acknowledge the risks, add the following entry to your <code>testvars</code> file as the first field in the list: <code>"acknowledged_risks": true</code>.</p>
-
-<div class="note">
-<p><strong>Note</strong>: If the risks are not acknowledged in the <code>testvars</code> file, the tests will not run.</p>
-</div>
-
-<h3 id="Step_5_Connect_to_USB_and_ADB_Forward_the_Device">Step 5: Connect to USB and ADB Forward the Device</h3>
-
-<p>Attach the Firefox OS device to your computer via USB.</p>
-
-<div class="note">
-<p><strong>Note</strong>: If you’re using an Ubuntu VM, after attaching the device ensure the VM sees the device and connects to it; in the VM select <strong>VM &gt; Removable Devices &gt; Your Device &gt; Connect</strong> and wait for the device to connect to the VM.</p>
-</div>
-
-<p>Now tell <code>adb</code> to forward the device port to GaiaTest using the following command:</p>
-
-<pre class="brush: bash">adb forward tcp:2828 tcp:2828</pre>
-
-<div class="note">
-<p><strong>Note</strong>: If you are using the Firefox OS Leo device, you must first tell ADB to be the root user, like so:</p>
-
-<pre>adb root
-adb forward tcp:2828 tcp:2828</pre>
-</div>
-
-<h3 id="Step_6_Run_a_Test">Step 6: Run a Test</h3>
-
-<p>Now you’re ready to actually try running a test. Use the following commands:</p>
-
-<pre class="brush: bash">cd {MTBF Driver Folder}
-MTBF_TIME=1d MTBF_CONF=conf/local.json mtbf --address=localhost:2828 --testvars=mytestvars.json</pre>
-
-<p>We can parse the <code>MTBF_TIME</code> by d(ay), h(our), or m(inute).</p>
-
-<p>If you get a “connection refused” error it means the device USB connection didn’t work; just repeat the device connection and try again.</p>
-
-<p>The Firefox OS device b2g process should now restart, then the specified test will run with a single iteration. If you watch the Firefox OS device, you’ll see the device UI being manipulated by Marionette. After the test finishes, a memory checkpoint will be performed.</p>
-
-<div class="note">
-<p><strong>Note</strong>: The Gaia-UI MTBF tests now grab the Firefox OS device’s b2g process RSS value for the memory use checkpoint (it used to be the V-SIZE value.)</p>
-</div>
-
-<p>The test result will be displayed in the terminal window. Note that this result doesn’t include the b2g process memory value; this value is stored in a text file, created at the time of the checkpoint in the <code>checkpoints</code> directory. To see the resulting b2g process, open this file. This "suite_summary" file will contain the average b2g process memory use (RSS) value, averaged from all the test checkpoints (in our example there was only one checkpoint.)</p>
-
-<p>There are two other files present in the <code>checkpoints</code> folder (assuming the test run was the "add contact" test):</p>
-
-<ul>
- <li>The <code>checkpoint_add_contact_(datetime)_summary.log</code> file contains a summary for the test run. This includes the number of iterations, all of the RSS value readings from each checkpoint, the average RSS value, etc.</li>
- <li>The <code>checkpoint_add_contact_(datetime).log</code> file contains the raw data received from each of the device checkpoints, from which the summary files were produced.</li>
-</ul>
-
-<h3 id="Step_7_Using_Variables_and_Config_Files">Step 7: Using Variables and Config Files</h3>
-
-<p>We use envrionment variable MTBF_TIME for running duration.  The other one is MTBF_CONF which refers to json file, specific runner options include test case repository and list.  A normal config file should look like </p>
-
-<pre><code>{
-  "memory_report": false,
-  "logcat": true,
-  "overall_status": true,
-  "b2g_status": true,
-  "get_event": true,
-  "rootdir": "tests/mtbf",
-  "workspace": "/tmp/workspace",
-  "manifest_prefix": "mtbf",
-  "archive": "output",
-  "runlist": "runlist/all.list",
-  "level": 4
-}</code></pre>
-
-<ul>
- <li>memory_report, locat, overall_status, b2g_status and get event help: options for collecting debug information.</li>
- <li>rootdir: root of test case repository for searching and matching in runlist.</li>
- <li>workspace: running materials will be stored here for replay.</li>
- <li>manifest_prefix: currently not available.</li>
- <li>archive: specifying folder for storing report and debug information</li>
- <li>runlist: json file by a list of test case file path.  Test cases will be randomly picked and put into running queue.</li>
- <li>level: specify how often a dummy case (to simulator user not focusing) should be triggered. level 0 is no test will be run, where level 5 means no dummy test enqueued.</li>
-</ul>
-
-<h2 id="Contributing_to_the_project">Contributing to the project</h2>
-
-<p>If you have any questions about the Firefox OS MTBF tests or are interested in contributing to this important automation development effort, feel free to contact us at wachen@mozilla.com</p>
-
-<h2 id="How_to_migrate_test_cases_from_Gaia-ui-tests">How to migrate test cases from Gaia-ui-tests</h2>
-
-<p>This section provides a guide to migrating tests between gaia-ui tests and MTBF.</p>
-
-<h3 id="Step_1_Rename" dir="ltr">Step 1: Rename</h3>
-
-<ul>
- <li><code>from MtbfTestCase import GaiaMtbfTestCase</code>
-
-  <ul>
-   <li>(original) <code>from gaiatest import GaiaTestCase</code></li>
-  </ul>
- </li>
- <li><code>class XXX(GaiaMtbfTestCase)</code>
-  <ul>
-   <li>(original) <code>class XXX(GaiaTestCase)</code></li>
-  </ul>
- </li>
- <li>If it has a <code>setUp()</code> or <code>tearDown()</code> method, use <code>GaiaMtbfTestCase</code>
-  <ul>
-   <li>(original) <code>GaiaTestCase</code></li>
-  </ul>
- </li>
-</ul>
-
-<h3 id="Step_2_Add" dir="ltr">Step 2: Add</h3>
-
-<ul>
- <li>If there's no <code>setUp()</code> method , add it before the general test function.</li>
- <li>Add <code>GaiaMtbfTestCase.setUp(self)</code> as the first step of <code>setUp()</code>.
-  <ul>
-   <li>Environment check/recovery and app initialization.</li>
-   <li><code>launch</code> &gt; <code>launch_by_touch</code> if possible.</li>
-   <li>Get the handle using <code>self.app_id</code>.</li>
-  </ul>
- </li>
- <li>If there's no <code>tearDown()</code> method, add it after the general test function.</li>
- <li>Add <code>GaiaMtbfTestCase.tearDown(self)</code> as the last step of <code>tearDown()</code>.
-  <ul>
-   <li>Handle data after the test is finished (delete/remove/move/etc.)</li>
-  </ul>
- </li>
-</ul>
-
-<h3 id="Step_3_Principles">Step 3: Principles</h3>
-
-<ul>
- <li>Modify <code>assert()</code> functions in your tests (make sure they work for multiple test cases.)</li>
- <li>If porting cases from Gaia-UI-Test, you need to declare <code>app</code> as a test class member.</li>
- <li>If multiple apps init/launch in a case; please refer to the <code>card_view</code> cases.
-  <ul>
-   <li>Unless your clean actions don't involve UI interactions, avoid this scenario if you can.</li>
-   <li>For example, use device manager to remove the file on the device.</li>
-   <li>In such cases, you may need to call <code>marionette.refresh()</code> to get the latest update.</li>
-  </ul>
- </li>
- <li>Replace <code>datetime.fromtimestamp</code> with <code>datetime.utcfromtimestamp</code> if you want to implement calendar related cases.</li>
-</ul>
-
-<h3 id="Step_4_About_apps">Step 4: About apps</h3>
-
-<ol>
- <li><code>apps</code> &gt; <code>mtbf_apps</code> if needed.</li>
- <li>Import original apps.</li>
- <li>Add <code>__init__()</code> and any functions you need.</li>
-</ol>
-
-<h3 id="Step_5_After_you_have_finished">Step 5: After you have finished</h3>
-
-<ol>
- <li>Test each test case using <em>Test full suite &gt; Test full suite with shuffle</em></li>
- <li>Check PEP8 errors</li>
- <li>Use a pull request to add your test cases to the main repo! Do not push directly.</li>
-</ol>
diff --git a/files/fr/archive/b2g_os/automated_testing/reftests/index.html b/files/fr/archive/b2g_os/automated_testing/reftests/index.html
deleted file mode 100644
index 6bab5de637..0000000000
--- a/files/fr/archive/b2g_os/automated_testing/reftests/index.html
+++ /dev/null
@@ -1,191 +0,0 @@
----
-title: Firefox OS reftests
-slug: Archive/B2G_OS/Automated_testing/Reftests
-tags:
-  - B2G
-  - Firefox OS
-  - Tests automatiques
-translation_of: Archive/B2G_OS/Automated_testing/Reftests
----
-<div class="summary">
-<p><span class="seoSummary">Les tests de référence (ou reftests), sont des tests simples qui comparent, deux rendus d'interface utilisateur, d'une application web séparément (Des éléments HTML, par exemple) pour vérifier si ils sont identiques ou non. Cet article vous fournit tout ce que vous devez savoir pour lancer la suite reftests de Mozilla sur B2G. Pour en savoir plus sur reftests, lisez <a href="/en-US/docs/Creating_reftest-based_unit_tests">Créer des tests unitaires basés sur reftest (Ressource en anglais)</a>.</span></p>
-</div>
-
-<h2 id="Prérequis_pour_lancer_reftests">Prérequis pour lancer reftests</h2>
-
-<p>Vous pouvez lancer <a href="/en-US/docs/Creating_reftest-based_unit_tests">reftests</a> sur B2G. Il est principalement essayé sur l'émulateur, mais en théorie doit fonctionner tout aussi bien sur des appareils. Dans cet article <code>$B2G_HOME</code> fait référence au clone du dépôt B2G. Vous trouverez ci-dessous ce que vous aurez besoin de compiler ou paramétrer, avant de pouvoir essayer de lancer les reftests B2G.</p>
-
-<div class="warning">
-<p>Si vous obtenez ce stacktrace pendant que vous jouez les reftests:</p>
-
-<p>ImportError: cannot import name expected</p>
-
-<div class="de2 li2">File "gecko-dev/objdir-b2g-ics-emulator/_tests/reftest/runreftestb2g.py", line <span class="nu0">16</span>, in &lt;module&gt;</div>
-
-<div class="de1 li1">    from b2g_desktop import run_desktop_reftest</div>
-
-<div class="de2 li2">File "Projects/gecko-dev/objdir-b2g-ics-emulator/_tests/reftest/b2g_desktop.py", line <span class="nu0">14</span>, in &lt;module&gt;</div>
-
-<div class="de2 li2">     from marionette import Marionette, expected</div>
-
-<div class="de2 li2"> </div>
-
-<div class="de2 li2">Ceci est un bogue connu sur https://bugzilla.mozilla.org/show_bug.cgi?id=1114474#c7</div>
-</div>
-
-<h3 id="Build_B2G_for_the_target_you're_testing">Build B2G for the target you're testing</h3>
-
-<p><a href="/en-US/docs/Mozilla/Boot_to_Gecko/Building_and_installing_Boot_to_Gecko">Regular B2G build instructions apply</a> — no need for any special build options.</p>
-
-<p>The B2G config that you will be using (what you pass to <code>./config.sh</code>) will probably be <code>emulator</code> as that is what reftests are typically run on. Before building B2G for the <code>emulator</code> config, pay special attention to the <a href="/en-US/docs/Mozilla/Firefox_OS/Firefox_OS_build_prerequisites#Emulator_build_issues" title="/en-US/docs/Mozilla/Firefox_OS/Firefox_OS_build_prerequisites#Emulator_build_issues">Emulator build issues</a> section in the <a href="/en-US/docs/Mozilla/Firefox_OS/Firefox_OS_build_prerequisites" title="/en-US/docs/Mozilla/Firefox_OS/Firefox_OS_build_prerequisites">Firefox OS build prerequisites</a> page.</p>
-
-<p>As usual, make sure <code>adb</code> is in your path and that it successfully connects to your running emulator or device. Try <code>adb devices</code> to make sure it is working ok.</p>
-
-<h2 id="Running_reftests">Running reftests</h2>
-
-<p>Having satisfied the above prerequisites, you can then run reftests using one of the following sets of terminal commands.</p>
-
-<h3 id="For_the_emulator">For the emulator</h3>
-
-<p>Use mach:</p>
-
-<pre>cd $B2G_HOME
-./mach reftest-remote</pre>
-
-<p>This will run all reftests. If you want to run a specific reftest, do the following:</p>
-
-<pre>cd $B2G_HOME
-./mach reftest-remote relative/path/from/B2G/to/reftest.list</pre>
-
-<h3 id="For_a_real_device"><strong>For a real device</strong></h3>
-
-<p>Running reftests on a device is not officially supported yet. One problem is that most devices don't support the minimum required resolution (800x1000) for many of the tests. But if you want to try anyway, you should be able to do so using the following steps:</p>
-
-<pre class="brush: bash">cd $B2G_HOME/objdir-gecko
-make package-tests
-source _virtualenv/bin/activate
-cd dist/test-package-stage/reftest
-python runreftestb2g.py --b2gpath $B2G_HOME --xre-path /path/to/dir/containing/desktop/xpcshell --ignore-window-size <code>relative/path/from/B2G/objdir-gecko/to/reftest.list</code></pre>
-
-<h2 id="Running_crashtests">Running crashtests</h2>
-
-<p>To run crashtests, do the following:</p>
-
-<pre>cd $B2G_HOME
-./mach crashtest-remote</pre>
-
-<p>This will run all crashtests. If you want to run a specific crashtest, do the following:</p>
-
-<pre>cd $B2G_HOME
-./mach reftest-remote relative/path/from/B2G/to/crashtests.list</pre>
-
-<h2 id="Running_jsreftests">Running jsreftests</h2>
-
-<p>JSReftests are not officially supported yet. See <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=972870">bug 972870</a> for progress updates on adding jsreftests to mach.</p>
-
-<h2 id="Running_reftest_with_non-default_options">Running reftest with non-default options</h2>
-
-<p>You can optionally add <code>--total-chunks</code> and <code>--this-chunks</code> arguments as you would with regular desktop reftests. Use:</p>
-
-<pre class="brush: bash">mach help reftest-remote</pre>
-
-<p>for a full list of supported arguments.</p>
-
-<h2 id="Running_reftest_with_a_downloaded_emulator">Running reftest with a downloaded emulator</h2>
-
-<p>If you've built B2G for another config (like otoro) and want to run the tests on an emulator, you can do so without building an emulator yourself. Just download the latest trunk arm emulator and do the following:</p>
-
-<pre class="brush: bash">pip install marionette-client
-python runreftestb2g.py --emulator arm --b2gpath path/to/emulator --xre-path /path/to/dir/containing/desktop/xpcshell --ignore-window-size <code>--emulator-res 800x1000 &lt;path_to_reftest_manifest&gt;</code></pre>
-
-<h2 id="Running_reftest_with_a_downloaded_emulator_and_downloaded_tests.zip_package">Running reftest with a downloaded emulator and downloaded tests.zip package</h2>
-
-<p>If you want to run reftests against a downloaded emulator and a downloaded <code>tests.zip</code> package, you should extract them both.</p>
-
-<p>Then run the following commands:</p>
-
-<pre class="brush: bash">cd $TESTS_ZIP_DIR/mozbase
-python setup_development.py
-cd $TESTS_ZIP_DIR/marionette
-python setup.py develop
-cd $TESTS_ZIP_DIR/reftest
-python runreftestb2g.py --emulator arm --b2gpath $EMULATOR_DIR --xre-path /path/to/dir/containing/desktop/xpcshell --ignore-window-size --emulator-res 800x1000 &lt;path_to_reftest_manifest&gt;</pre>
-
-<div class="note">
-<p><strong>Note</strong>: For best results, you should perform the above steps using a <a href="/en-US/docs/Python/Virtualenv" title="/en-US/docs/Python/Virtualenv">Python virtualenv</a>.</p>
-</div>
-
-<h2 id="Troubleshooting">Troubleshooting</h2>
-
-<p>The following sections provide some answers to common problems encountered when trying to use reftests.</p>
-
-<h3 id="I_can't_build_the_emulator!">I can't build the emulator!</h3>
-
-<p>If you have trouble building B2G in the <code>emulator</code> config, check out the <a href="/en-US/docs/Mozilla/Firefox_OS/Firefox_OS_build_prerequisites#Emulator_build_issues" title="/en-US/docs/Mozilla/Firefox_OS/Firefox_OS_build_prerequisites#Emulator_build_issues">Emulator build issues</a> section in the <a href="/en-US/docs/Mozilla/Firefox_OS/Firefox_OS_build_prerequisites" title="/en-US/docs/Mozilla/Firefox_OS/Firefox_OS_build_prerequisites">Firefox OS build prerequisites</a> page.</p>
-
-<h3 id="Check_that_your_B2G_buildemulator_works_and_that_ADB_can_connect_to_it">Check that your B2G build/emulator works and that ADB can connect to it</h3>
-
-<p>First check that your B2G build runs normally. If this is an emulator build, then <code>./run-emulator.sh</code> should work: it should start up the emulator and boot B2G inside it. If it doesn't, get the log from <code>adb logcat</code> and ask for help. If ADB fails to connect to the running emulator, make sure that you have no other (Android or B2G) devices connected, and try passing in the <code>-e</code> option to tell adb to focus on the emulator:</p>
-
-<pre class="brush: bash">adb logcat -e</pre>
-
-<p>Once you have verified that your B2G build/emulator works normally and that ADB can connect to it, the next step is to verify that your xpcshell desktop executable runs normally. If you built B2G for a real device and ADB can't connect to it, check out <a href="/en-US/docs/Mozilla/Firefox_OS/Debugging/Connecting_a_Firefox_OS_device_to_the_desktop" title="/en-US/docs/Mozilla/Firefox_OS/Debugging/Connecting_a_Firefox_OS_device_to_the_desktop">Connecting a Firefox OS device to the desktop</a>.</p>
-
-<div class="note">
-<p><strong>Note</strong>: None of the errors below should occur if you are using mach. If you have problems with mach, please file a bug under Testing/Reftest and CC :ahal</p>
-</div>
-
-<h3 id="Check_that_you_can_run_your_desktop_xpcshell_executable">Check that you can run your desktop xpcshell executable</h3>
-
-<p>The <code>python runreftestb2g.py</code> command line above will try to run xpcshell on your desktop with the path specified by the <code>--xre-path</code> argument. Check that running xpcshell from the current directory with this relative path actually works.</p>
-
-<p>For example, suppose that your command line contains:</p>
-
-<pre class="brush: bash">--xre-path /hack/mozilla-central/objdir/dist/bin</pre>
-
-<p>Try running this from the same directory as you want to run <code>python runreftestb2g.py</code> from<code>:</code></p>
-
-<pre><code class="brush: bash">$ /hack/mozilla-central/objdir/dist/bin/xpcshell</code></pre>
-
-<p>This should land you in a special-looking shell like this:</p>
-
-<pre class="brush: bash">js&gt;</pre>
-
-<p>If this fails with an error message complaining about being unable to find or load certain shared libraries, like this</p>
-
-<pre class="brush: bash">/hack/mozilla-central/objdir/dist/bin/xpcshell: error while loading shared libraries: libxul.so: cannot open shared object file: No such file or directory</pre>
-
-<p>then you need to set the right environment variable so that it looks for these libraries in the same directory. On Linux, you would set <code>LD_LIBRARY_PATH</code> to the same directory as you want to pass as <code>--xre-path</code>. For example, this should work:</p>
-
-<pre class="brush: bash">LD_LIBRARY_PATH=<code>/hack/mozilla-central/objdir/dist/bin <code>/hack/mozilla-central/objdir/dist/bin/xpcshell</code></code></pre>
-
-<p>On Mac OSX, the environment variable to set is <code>DYLD_LIBRARY_PATH</code>.</p>
-
-<h3 id="Check_that_reftest_can_find_httpd.js">Check that reftest can find httpd.js</h3>
-
-<p>If reftest still fails to run — returning early with an error — the next most likely cause of trouble is it failing to find certain files that it needs to load. The first file that it could fail to find is <code>httpd.js</code>. Typically, the reason why it would not find it is that you accidentally built xpcshell with <code>--disable-tests</code>. So, make sure that the path you pass to <code>--xre-path</code> does contain a <code>httpd.js</code> file under the <code>components</code> subdirectory.</p>
-
-<p>This is good:</p>
-
-<pre class="brush: bash">$ find /hack/mozilla-central/objdir/dist/bin/ -name httpd.js
-/hack/mozilla-central/objdir/dist/bin/components/httpd.js
-/hack/mozilla-central/objdir/dist/bin/modules/commonjs/sdk/test/httpd.js</pre>
-
-<p>This is bad (was caused by <code>--disable-tests</code>):</p>
-
-<pre class="brush: bash">$ find /hack/mozilla-central/objdir/dist/bin/ -name httpd.js
-/hack/mozilla-central/objdir/dist/bin/modules/commonjs/sdk/test/httpd.js</pre>
-
-<h3 id="Check_that_you_didn't_forget_to_make_package-tests">Check that you didn't forget to make package-tests</h3>
-
-<p>Forgetting the <code>make package-tests</code> step described above would certainly explain why nothing works.</p>
-
-<h3 id="Check_that_you_passed_a_correct_relative_path_to_the_reftest.list">Check that you passed a correct relative path to the reftest.list</h3>
-
-<p>The final argumant in the command line running reftest is the <code>relative/path/from/B2G/objdir-gecko/to/reftest.list</code>. This must be a relative path from the <code>B2G/objdir-gecko</code> directory to a <code>reftest.list</code> file under it. So check that a <code>reftest.list </code>file is actually present there! If it isn't, compare your command line to the sample command line below, and/or check that you didn't forget to make <code>package-tests</code> as explained above.</p>
-
-<p>Sample command line:</p>
-
-<pre class="brush: bash">$ LD_LIBRARY_PATH=/hack/mozilla-central/objdir/dist/bin python runreftestb2g.py --b2gpath /hack/b2g/B2G/ --xre-path /hack/mozilla-central/objdir/dist/bin  --ignore-window-size --emulator arm --emulator-res 800x1000 tests/layout/reftests/css-gradients/reftest.list</pre>
-
-<p>Here, we are running only the <code>css-gradients</code> directory of reftests.</p>
diff --git a/files/fr/archive/b2g_os/automated_testing/test_execution_chart/index.html b/files/fr/archive/b2g_os/automated_testing/test_execution_chart/index.html
deleted file mode 100644
index f01bb8274f..0000000000
--- a/files/fr/archive/b2g_os/automated_testing/test_execution_chart/index.html
+++ /dev/null
@@ -1,89 +0,0 @@
----
-title: Tableau d'exécution des tests
-slug: Archive/B2G_OS/Automated_testing/Test_Execution_Chart
-translation_of: Archive/B2G_OS/Automated_testing/Test_Execution_Chart
----
-<p></p>
-
-<div class="summary">
-<p>Il y a différentes plate-formes B2G actuellement utilisées par les développeurs. <span class="seoSummary">Le tableau des exécutions de tests montre quels sont les outils de tests supportés pour chaque plate-forme, ainsi que les plate-formes actuellement utilisées pour l'intégration en continu.</span></p>
-</div>
-
-<h2 id="Légende">Légende</h2>
-
-<ul>
- <li>N : Non supporté</li>
- <li>S : Supporté</li>
- <li>J: Actuellement exécuté dans Jenkins</li>
- <li>T: Actuellement exécuté dans TBPL</li>
- <li>Tr: Actuellement exécuté avec <a href="https://travis-ci.org/mozilla-b2g/gaia">Travis</a></li>
-</ul>
-
-<table class="standard-table">
- <thead>
-  <tr>
-   <th>Outil de test</th>
-   <th>version b2g pour bureau</th>
-   <th>émulateur b2g</th>
-   <th>versions pour appareils</th>
-  </tr>
- </thead>
- <tbody>
-  <tr>
-   <th>b2gperf</th>
-   <td style="text-align: center;">N</td>
-   <td style="text-align: center;">N</td>
-   <td style="text-align: center;">S J</td>
-  </tr>
-  <tr>
-   <th>eideticker</th>
-   <td style="text-align: center;">N</td>
-   <td style="text-align: center;">N</td>
-   <td style="text-align: center;">S</td>
-  </tr>
-  <tr>
-   <th>tests d'intégration gaia</th>
-   <td style="text-align: center;">S Tr</td>
-   <td style="text-align: center;">tbd</td>
-   <td style="text-align: center;">tbd</td>
-  </tr>
-  <tr>
-   <th>tests ui gaia</th>
-   <td style="text-align: center;">S T Tr</td>
-   <td style="text-align: center;">N</td>
-   <td style="text-align: center;">S J</td>
-  </tr>
-  <tr>
-   <th>tests unitaires gaia</th>
-   <td style="text-align: center;">S T Tr</td>
-   <td style="text-align: center;">N</td>
-   <td style="text-align: center;">N</td>
-  </tr>
-  <tr>
-   <th>tests émulateur webapi</th>
-   <td style="text-align: center;">N</td>
-   <td style="text-align: center;">S T</td>
-   <td style="text-align: center;">N</td>
-  </tr>
-  <tr>
-   <th>mochitests</th>
-   <td style="text-align: center;">S</td>
-   <td style="text-align: center;">S T</td>
-   <td style="text-align: center;">S</td>
-  </tr>
-  <tr>
-   <th>reftests</th>
-   <td style="text-align: center;">N</td>
-   <td style="text-align: center;">S T</td>
-   <td style="text-align: center;">N</td>
-  </tr>
-  <tr>
-   <th>tests xpcshell</th>
-   <td style="text-align: center;">N</td>
-   <td style="text-align: center;">S T</td>
-   <td style="text-align: center;">N</td>
-  </tr>
- </tbody>
-</table>
-
-<p> </p>
diff --git a/files/fr/archive/b2g_os/automated_testing/tests_cppunit/index.html b/files/fr/archive/b2g_os/automated_testing/tests_cppunit/index.html
deleted file mode 100644
index 3f833b952f..0000000000
--- a/files/fr/archive/b2g_os/automated_testing/tests_cppunit/index.html
+++ /dev/null
@@ -1,44 +0,0 @@
----
-title: Tests Cppunit
-slug: Archive/B2G_OS/Automated_testing/Tests_Cppunit
-tags:
-  - Automatisation
-  - cppunit
-  - tests
-translation_of: Archive/B2G_OS/Automated_testing/Cppunit_Tests
----
-<div class="summary">
-<p><span class="seoSummary">Les tests Cppunit, sont des tests unitaires sans tête (headless) Gecko C++. Vous pouvez lancer les tests Cppunit sur B2G; dans cet article, nous verrons comment les réaliser. Actuellement, les tests sont effectués principalement sur l'émulateur, mais devrait en théorie fonctionner aussi bien sur les appareils.</span></p>
-</div>
-
-<div class="note">
-<p><strong>A noter</strong>: Dans cet article, <code>$B2G_HOME</code> fait référence au clone du dépôt B2G.</p>
-</div>
-
-<h2 id="À_la_dur">À la dur</h2>
-
-<p>Actuellement, il n'y a pas de commande mach pour lancer les tests cppunit, alors nous sommes cantonnés à les lancer "à la dur".</p>
-
-<h3 id="Prérequis">Prérequis</h3>
-
-<ul>
- <li>Vous devez compiler B2G pour la cible que vous testez (voir: <a href="/fr/Firefox_OS/Building_and_installing_Firefox_OS">Compiler et installer Firefox OS</a>). Actuellement, seuls les compilations de l'émulateur sont supportés, cependant d'autres appareils peuvent fonctionner.</li>
- <li>Vous devez installer quelques paquetages Python, que ce soit pour un environnement virtuel ou autre chose:
-  <pre>cd $GECKO_DIR/testing/mozbase
-python setup_development.py
-cd $GECKO_DIR/testing/marionette/client
-python setup.py develop
-</pre>
- </li>
- <li>Assurez vous qu'<code>adb</code> soit dans votre variable d'environnement path, ou spécifiez le chemin avec <code>--adbpath</code> (sur Linux il se trouve dans <code>$B2G_HOME/out/host/linux-x86/bin/adb</code><em>.</em>)</li>
- <li>Ayez une copie en local de <a href="http://busybox.net/downloads/binaries/latest/busybox-armv6l">Busybox</a> (ce n'est pas strictement nécessaire, mais peut réduire le temps de mise en place de manière significative.)</li>
-</ul>
-
-<h3 id="Lancer_les_tests">Lancer les tests</h3>
-
-<p>Vous pouvez alors lancer les tests xpcshell en démarrant d'abord un émulateur puis en exécutant les commandes suivante:</p>
-
-<pre>cd $B2G_HOME/objdir-gecko
-make package-tests
-cd dist/test-stage/cppunittests
-python remotecppunittests.py --xre-path $B2G_HOME/objdir-gecko/dist/bin --adbpath $ADB_PATH --dm_trans=adb --addEnv LD_LIBRARY_PATH=/vendor/lib:/system/lib:/system/b2g &lt;test1&gt; &lt;test2&gt; ...</pre>
author	Peter Bengtsson <mail@peterbe.com>	2020-12-08 21:46:22 -0500
committer	Peter Bengtsson <mail@peterbe.com>	2020-12-08 21:46:22 -0500
commit	a065e04d529da1d847b5062a12c46d916408bf32 (patch)
tree	fe0f8bcec1ff39a3c499a2708222dcf15224ff70 /files/fr/archive/b2g_os/automated_testing
parent	218934fa2ed1c702a6d3923d2aa2cc6b43c48684 (diff)
download	translated-content-a065e04d529da1d847b5062a12c46d916408bf32.tar.gz translated-content-a065e04d529da1d847b5062a12c46d916408bf32.tar.bz2 translated-content-a065e04d529da1d847b5062a12c46d916408bf32.zip