prise en compte des remarques

library/unittest.po

@@ -378,9 +378,9 @@ msgid ""
 "test fail or error and is added to the failure messages."
 msgstr ""
 "Les flux de sortie et d'erreur standards sont mis en mémoire tampon pendant "
-"l'exécution des tests. Les résultats d'un test réussi ne sont pas pris en "
-"compte. Un test en échec ou en erreur est affiché sur la sortie et est  "
-"ajouté aux messages d'erreur."
+"l'exécution des tests. L'affichage produit par un test réussi n'est pas pris "
+"en compte. Les sorties d'affichages d'un test en échec ou en erreur sont "
+"conservés et  ajoutés aux messages d'erreur."
 
 #: ../Doc/library/unittest.rst:212
 msgid ""
@@ -402,8 +402,7 @@ msgstr ""
 
 #: ../Doc/library/unittest.rst:220
 msgid "Stop the test run on the first error or failure."
-msgstr ""
-"Arrête l'exécution des tests lors du premier cas d'erreur ou d'échec."
+msgstr "Arrête l'exécution des tests lors du premier cas d'erreur ou d'échec."
 
 #: ../Doc/library/unittest.rst:224
 msgid ""
@@ -494,8 +493,9 @@ msgid ""
 "Test discovery is implemented in :meth:`TestLoader.discover`, but can also "
 "be used from the command line. The basic command-line usage is::"
 msgstr ""
-"La découverte de tests est implémentée dans :meth:`TestLoader.discover`, mais "
-"peut également être utilisée depuis la ligne de commande. Par exemple  ::"
+"La découverte de tests est implémentée dans :meth:`TestLoader.discover`, "
+"mais peut également être utilisée depuis la ligne de commande. Par exemple "
+" ::"
 
 #: ../Doc/library/unittest.rst:277
 msgid ""
@@ -612,12 +612,11 @@ msgid ""
 "`TestCase` or use :class:`FunctionTestCase`."
 msgstr ""
 "Les éléments de base des tests unitaires sont les :dfn:`scénarios de tests`  "
-"(*test cases* en anglais) --- Des "
-"scénarios uniques qui sont mis en place et exécutés pour vérifier qu'ils "
-"sont corrects.  Dans :mod:`unittest`, les scénarios de test sont représentés "
-"par des instances de :class:`unittest.TestCase`. Pour créer vos propres "
-"scénarios de test, vous devez écrire des sous-classes de :class:`TestCase` "
-"ou utiliser :class:`FunctionTestCase`."
+"(*test cases* en anglais) --- Des scénarios uniques qui sont mis en place et "
+"exécutés pour vérifier qu'ils sont corrects.  Dans :mod:`unittest`, les "
+"scénarios de test sont représentés par des instances de :class:`unittest."
+"TestCase`. Pour créer vos propres scénarios de test, vous devez écrire des "
+"sous-classes de :class:`TestCase` ou utiliser :class:`FunctionTestCase`."
 
 #: ../Doc/library/unittest.rst:347
 msgid ""
@@ -671,8 +670,8 @@ msgid ""
 "the test method names with respect to the built-in ordering for strings."
 msgstr ""
 "L'ordre dans lequel les différents tests sont exécutés est déterminé en "
-"classant les noms des méthodes de test en fonction de la relation d'ordre des "
-"chaines de caractères ."
+"classant les noms des méthodes de test en fonction de la relation d'ordre "
+"des chaines de caractères ."
 
 #: ../Doc/library/unittest.rst:393
 msgid ""
@@ -709,10 +708,11 @@ msgid ""
 "test."
 msgstr ""
 "Un tel environnement de travail pour le code de test s'appelle un :dfn:"
-"`aménagement de test` (*fixture* en anglais).  Une nouvelle instance de *TestCase* est créée sous la forme d'un "
-"dispositif de test unique utilisé pour exécuter chaque méthode de test "
-"individuelle.  Ainsi :meth:`~TestCase.setUp`, :meth:`~TestCase.tearDown` et :"
-"meth:`~TestCase.__init__` ne sont appelées qu'une fois par test."
+"`aménagement de test` (*fixture* en anglais).  Une nouvelle instance de "
+"*TestCase* est créée sous la forme d'un dispositif de test unique utilisé "
+"pour exécuter chaque méthode de test individuelle.  Ainsi :meth:`~TestCase."
+"setUp`, :meth:`~TestCase.tearDown` et :meth:`~TestCase.__init__` ne sont "
+"appelées qu'une fois par test."
 
 #: ../Doc/library/unittest.rst:418
 msgid ""
@@ -727,8 +727,8 @@ msgstr ""
 "des fonctionnalités qu'ils testent. :mod:`unittest` fournit un mécanisme "
 "pour cela : la :dfn:`suite de tests`, représentée par :class:`TestSuite` du "
 "module :mod:`unittest`. Dans la plupart des cas, appeler :func:`unittest."
-"main` fait correctement les choses et trouve tous les scénarios de test du module pour "
-"vous et les exécute."
+"main` fait correctement les choses et trouve tous les scénarios de test du "
+"module pour vous et les exécute."
 
 #: ../Doc/library/unittest.rst:425
 msgid ""
@@ -745,10 +745,10 @@ msgid ""
 "are several advantages to placing the test code in a separate module, such "
 "as :file:`test_widget.py`:"
 msgstr ""
-"Vous pouvez placer les définitions des scénarios de test et des suites de test "
-"dans le même module que le code à tester (tel que :file:`composant.py`), "
-"mais il y a plusieurs avantages à placer le code de test dans un module séparé, "
-"tel que :file:`test_composant.py` :"
+"Vous pouvez placer les définitions des scénarios de test et des suites de "
+"test dans le même module que le code à tester (tel que :file:`composant."
+"py`), mais il y a plusieurs avantages à placer le code de test dans un "
+"module séparé, tel que :file:`test_composant.py` :"
 
 #: ../Doc/library/unittest.rst:443
 msgid "The test module can be run standalone from the command line."
@@ -880,8 +880,8 @@ msgid ""
 "Skipping a test is simply a matter of using the :func:`skip` :term:"
 "`decorator` or one of its conditional variants."
 msgstr ""
-"Ignorer un test consiste à utiliser le :term:`décorateur <decorator>` :func:`skip`  "
-"term:`decorator` ou une de ses variantes conditionnelles."
+"Ignorer un test consiste à utiliser le :term:`décorateur <decorator>` :func:"
+"`skip`  ou une de ses variantes conditionnelles."
 
 #: ../Doc/library/unittest.rst:515
 msgid "Basic skipping looks like this::"
@@ -971,9 +971,9 @@ msgid ""
 "have :func:`setUpModule` or :func:`tearDownModule` run."
 msgstr ""
 "Les tests ignorés ne lancent ni :meth:`~TestCase.setUp` ni :meth:`~TestCase."
-"tearDown`. Les classes ignorées ne lancent ni :meth:`~TestCase."
-"setUpClass` ni :meth:`~TestCase.tearDownClass`. Les modules "
-"sautés n'ont pas :func:`setUpModule` ou :func:`tearDownModule` d'exécutés."
+"tearDown`. Les classes ignorées ne lancent ni :meth:`~TestCase.setUpClass` "
+"ni :meth:`~TestCase.tearDownClass`. Les modules sautés n'ont pas :func:"
+"`setUpModule` ou :func:`tearDownModule` d'exécutés."
 
 #: ../Doc/library/unittest.rst:606
 msgid "Distinguishing test iterations using subtests"
@@ -1043,10 +1043,10 @@ msgid ""
 "named *methodName*. In most uses of :class:`TestCase`, you will neither "
 "change the *methodName* nor reimplement the default ``runTest()`` method."
 msgstr ""
-"Chaque instance de la classe :class:`TestCase` n'exécute qu'une seule méthode "
-"de base : la méthode nommée *methodName* . Dans la plupart des utilisations "
-"de la classe :class:`TestCase`, vous n'avez pas à changer le nom de la "
-"méthode, ni à réimplémenter la méthode ``runTest()``."
+"Chaque instance de la classe :class:`TestCase` n'exécute qu'une seule "
+"méthode de base : la méthode nommée *methodName* . Dans la plupart des "
+"utilisations de la classe :class:`TestCase`, vous n'avez pas à changer le "
+"nom de la méthode, ni à réimplémenter la méthode ``runTest()``."
 
 #: ../Doc/library/unittest.rst:692
 msgid ""
@@ -1102,8 +1102,8 @@ msgid ""
 msgstr ""
 "Méthode appelée immédiatement après l'appel de la méthode de test et "
 "l'enregistrement du résultat.  Elle est appelée même si la méthode de test a "
-"levé une exception, de sorte que l'implémentation dans les sous-classes de "
-"contrôles d'état interne à la classe doit être fait avec précaution.  Toute "
+"levé une exception. De fait, l'implémentation d'un sous-classes doit être "
+"fait avec précaution  si vous vérifiez l'état interne de la classe. Toute "
 "exception, autre que :exc:`AssertionError` ou :exc:`SkipTest`, levée par "
 "cette méthode est considérée comme une erreur supplémentaire plutôt que "
 "comme un échec du test (augmentant ainsi le nombre total des erreurs "
@@ -1132,8 +1132,8 @@ msgid ""
 "decorated as a :meth:`classmethod`::"
 msgstr ""
 "Méthode de classe appelée après l'exécution des tests de la classe en "
-"question. ``tearDownClass`` est appelée avec la classe comme seul argument et "
-"doit être décorée comme une :meth:`classmethod`  ::"
+"question. ``tearDownClass`` est appelée avec la classe comme seul argument "
+"et doit être décorée comme une :meth:`classmethod`  ::"
 
 #: ../Doc/library/unittest.rst:757
 msgid ""
@@ -2057,11 +2057,11 @@ msgid ""
 "also raised if either of the parameters are of the wrong type. These methods "
 "are used by default when comparing lists or tuples with :meth:`assertEqual`."
 msgstr ""
-"Vérifie que deux listes ou deux n-uplets sont égaux.  Si ce n'est pas le cas, "
-"un message d'erreur qui ne montre que les différences entre les deux est "
-"généré.  Une erreur est également signalée si l'un ou l'autre des paramètres "
-"n'est pas du bon type. Ces méthodes sont utilisées par défaut pour comparer "
-"des listes ou des couples avec :meth:`assertEqual`."
+"Vérifie que deux listes ou deux n-uplets sont égaux.  Si ce n'est pas le "
+"cas, un message d'erreur qui ne montre que les différences entre les deux "
+"est généré.  Une erreur est également signalée si l'un ou l'autre des "
+"paramètres n'est pas du bon type. Ces méthodes sont utilisées par défaut "
+"pour comparer des listes ou des couples avec :meth:`assertEqual`."
 
 #: ../Doc/library/unittest.rst:1308
 msgid ""
@@ -2648,7 +2648,7 @@ msgid ""
 "derived :class:`testCaseClass`."
 msgstr ""
 "Renvoie une suite de tous les cas de test contenus dans la classe :class:"
-"`TestCase`\\ Dérivée de la classe :class:`testCaseClass`."
+"`TestCaseClass`\\ dérivée de :class:`testCase`."
 
 #: ../Doc/library/unittest.rst:1613
 msgid ""
@@ -3634,8 +3634,8 @@ msgid ""
 "``load_tests`` function for a test package would look like::"
 msgstr ""
 "Comme le motif est passé à ``load_tests``, le paquet est libre de continuer "
-"(et potentiellement de modifier) la découverte des tests. Une fonction 'ne "
-"rien faire' ``load_tests`` pour un paquet de test ressemblerait à  ::"
+"(et potentiellement de modifier) la découverte des tests. Une fonction « ne "
+"rien faire » ``load_tests`` pour un paquet de test ressemblerait à  ::"
 
 #: ../Doc/library/unittest.rst:2185
 msgid ""
@@ -3687,8 +3687,8 @@ msgid ""
 "care."
 msgstr ""
 "Notez que les aménagements de tests partagés ne fonctionnent pas bien avec "
-"les fonctions[potentielles] comme la parallélisation de test et qu'ils "
-"brisent l'isolation de test. Ils doivent être utilisés avec précaution."
+"de « potentielles » fonctions comme la parallélisation de test et qu'ils "
+"brisent l'isolation des tests. Ils doivent être utilisés avec parcimonie."
 
 #: ../Doc/library/unittest.rst:2209
 msgid ""
@@ -3808,8 +3808,8 @@ msgid ""
 msgstr ""
 "L'option :option:`-c/--catch <unittest -c>` en ligne de commande pour "
 "*unittest*, ainsi que le paramètre ``catchbreak`` vers :func:`unittest."
-"main()`, permettent une manipulation plus conviviale du contrôle-C pendant "
-"un test. Avec l'activation de ``catchbreak``, l'utilisation du contrôle-C "
+"main()`, permettent une utilisation simplifiée du contrôle-C pendant un "
+"test. Avec l'activation de ``catchbreak``, l'utilisation du contrôle-C "
 "permet de terminer le test en cours d'exécution, et le test se termine et "
 "rapporte tous les résultats obtenus jusqu'à présent. Un deuxième contrôle-C "
 "lève une exception classique :exc:`KeyboardInterrupt`."