espoir/python-docs-fr
Fork 0
forked from AFPy/python-docs-fr
Code Pull requests Activity

prise en compte des remarques

Browse source
This commit is contained in:
Pierre Bousquié 2019-02-24 11:57:36 +01:00 • committed by Julien Palard
commit b161d67657
1 changed files with 50 additions and 50 deletions
Download patch file Download diff file Expand all files Collapse all files

100
library/unittest.po
View file

@ -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`."