essai - En ligne dans le Cloud

PROGRAMME:

Nom

essai - exécuter des tests unitaires

SYNOPSIS

procès [ Options ] [ filet | paquet | module | Cas de test | méthode d'essai ]...

procès --Aidez-moi | -h

DESCRIPTION

essai charge et exécute une suite de tests unitaires, obtenus à partir de modules, de packages et de fichiers
répertorié sur la ligne de commande.

trial prendra soit des noms de fichiers, soit des noms Python complets comme arguments. Ainsi
`trial myproject/foo.py', `trial myproject.foo' et `trial
myproject.foo.SomeTestCase.test_method' sont tous des moyens valides d'invoquer un essai. Plusieurs tels
les arguments sont également acceptés, et leur ordre déterminera l'ordre dans lequel les
les tests correspondants sont exécutés.

Après avoir exécuté la suite de tests donnée, le rapporteur de test par défaut imprime un résumé du test
Cours. Il s'agit du mot « PASSED » (si tous les tests se sont déroulés comme prévu) ou « FAILED » (le cas échéant
le test s'est comporté de manière inattendue) suivi d'un décompte des différents types de résultats de test
rencontré. Les types possibles de résultats de test comprennent :

succès
Des tests qui ont réussi toutes leurs affirmations et se sont terminés sans erreur. Ceux-ci sont
marqué « PASSED » dans la sortie de test normale.

échecs
Tests qui ont échoué à une assertion, appelés self.fail() ou explicitement déclenchés
self.failureException pour une raison quelconque. Ceux-ci sont marqués "FAILED" dans le test normal
sortie.

erreurs Tests qui ont levé une exception inattendue (y compris AssertionError), tests qui
la méthode tearDown () a déclenché une exception, des tests qui s'exécutent plus longtemps que
l'intervalle de délai d'attente, les tests qui ont provoqué l'appel de quelque chose twisted.python.log.err()
sans appeler par la suite self.flushLoggedErrors(), tests qui quittent le réacteur
dans un état impur, etc. Ceux-ci sont marqués "ERREUR" dans la sortie de test normale.

Notez que parce que des erreurs peuvent être causées après le retour de la méthode de test réelle, il est
possible pour un seul test d'être signalé à la fois comme une erreur et un échec, et donc
le nombre total de résultats de test peut être supérieur au nombre total de tests
réalisé.

skips Tests qui ont été ignorés, généralement en raison de dépendances manquantes. Ceux-ci sont marqués
"SKIPPED" dans la sortie de test normale.

échecs attendus
Les tests qui ont échoué, mais qui devaient échouer, généralement parce que le test est destiné à un
fonctionnalité qui n'a pas encore été implémentée. Ceux-ci sont marqués "TODO" dans la normale
sortie de test.

des succès inattendus
Tests qui auraient dû être répertoriés sous expectFailures, sauf que pour certains
raison pour laquelle le test a réussi. Ceux-ci sont marqués "SUCCESS !?!" dans la sortie de test normale.

OPTIONS

-j, --travaux nombre
Définissez le nombre de processus de travail à exécuter. Cela entre en conflit avec le débogage, exitfirst
et les options de profil.

-b, --déboguer
Exécutez les tests dans un débogueur. Si ce débogueur est 'pdb' (ce qui est la valeur par défaut si
non spécifié), un `.pdbrc' sera chargé depuis le répertoire courant s'il existe.
Effectue également le débogage post-mortem sur les exceptions.

-B, --debug-stacktraces
Signaler la création différée et les traces de la pile de rappel.

--couverture
Générer des informations de couverture dans le sous-répertoire « couverture » ​​de la période d'essai
répertoire (`_trial_temp' par défaut). Pour chaque module Python touché par le
l'exécution des tests donnés, un fichier sera créé dans le répertoire de couverture
nommé pour le nom complet du module avec le suffixe « .cover ». Par exemple,
parce que le lanceur de test d'essai est écrit en Python, le répertoire de couverture sera
contiennent presque toujours un fichier nommé `twisted.trial.runner.cover'.

Chaque fichier `.cover' contient une copie du code source Python du module en question,
avec un préfixe au début de chaque ligne contenant les informations de couverture. Pour
lignes non exécutables (lignes blanches, commentaires, etc.) le préfixe est vide.
Pour les lignes exécutables qui ont été exécutées au cours de la suite de tests, le préfixe est un
nombre indiquant le nombre de fois que cette ligne a été exécutée. La chaîne `>>>>>>'
préfixe les lignes exécutables qui n'ont pas été exécutées au cours de la suite de tests.

Notez que cette fonctionnalité utilise la fonction sys.settrace() de Python, donc teste que
call sys.settrace() eux-mêmes sont susceptibles de casser la fonctionnalité de couverture de trial.

--débogueur
Spécifie le débogueur à utiliser lorsque l'option --debug est transmise. L'argument
doit être le nom complet d'un objet qui implémente la même interface
comme le `pdb' de la bibliothèque standard.

--disablegc
Désactivez le ramasse-miettes pendant la durée de l'exécution du test. Comme chaque test est
run, trial enregistre les objets TestResult, ce qui signifie que les déchets de Python
le collecteur a plus d'objets non-poubelle à parcourir, ce qui rend chaque poubelle-
la collecte s'exécute un peu plus lentement. La désactivation complète du ramasse-miettes fera
certaines suites de tests se terminent plus rapidement (contraste --force-gc, ci-dessous), au prix de
augmentant (peut-être grandement) la consommation de mémoire. Cette option fait également des tests
légèrement plus déterministe, ce qui peut aider au débogage dans des circonstances extrêmes.

-e, --rterreurs
Imprimez les traces sur la sortie standard dès qu'elles se produisent.

--force-gc
Exécutez gc.collect() avant et après chaque scénario de test. Cela peut être utilisé pour isoler
erreurs qui se produisent lorsque les objets sont collectés. Cette option serait la valeur par défaut,
sauf que cela ralentit l'exécution des tests environ dix fois.

-h, --Aidez-moi
Imprimez un message d'utilisation sur la sortie standard, puis quittez.

--help-commande
Imprimez une liste des commandes possibles dans lesquelles les méthodes de test TestCase peuvent être exécutées, puis
sortir. Les commandes peuvent être utilisées avec l'option --order décrite ci-dessous.

--help-journalistes
Imprimez une liste de rapporteurs valides sur la sortie standard, puis quittez. Les journalistes peuvent être
sélectionné avec l'option --reporter décrite ci-dessous.

--help-reacteurs
Imprimez une liste des réacteurs possibles sur la sortie standard, puis quittez. Pas tous répertoriés
des réacteurs sont disponibles sur chaque plate-forme. Les réacteurs peuvent être sélectionnés avec le
--reactor option décrite ci-dessous.

-l, --fichier journal fichier journal
Dirigez le journal vers un autre fichier. Le fichier par défaut est `test.log'. fichier journal is
par rapport à _trial_temp.

-n, - à sec
Passez tous les tests et faites-les passer sans courir.

-N, --pas de récure
Par défaut, la version d'essai parcourt les packages pour trouver chaque module dans chaque
sous-paquet. Sauf si vous spécifiez cette option.

--nopm Ne sautez pas automatiquement dans le débogueur pour une analyse post-mortem des exceptions.
Utilisable uniquement avec --debug.

--ordre de commander
Spécifiez dans quel ordre exécuter les méthodes de test individuelles dans les cas de test donnés.
Par défaut, ils sont exécutés par ordre alphabétique. Voir --help-order pour une liste d'autres
valeurs.

--profil
Exécutez des tests sous le profileur Python.

-r, --réacteur réacteur
Choisissez le réacteur à utiliser. Voir --help-reactors pour une liste.

--récursionlimite limite
Définissez la limite de récursivité de Python. Voir sys.setrecursionlimit().

--journaliste journaliste
Sélectionnez le journaliste à utiliser pour la sortie de l'essai. Utilisez l'option --help-reporters pour
voir une liste de déclarants valides.

-x, --sortie en premier
Arrêtez l'exécution du test après le premier test qui n'a pas réussi. Ceci comprend
échecs, erreurs ou succès inattendus. Ne fonctionnera pas avec l'option --jobs
actuellement.

--vomir Imprimez un journal incroyablement détaillé de tout ce qui se passe. Utile lors du débogage
se bloque ou se verrouille dans un code complexe.

--tbformat le format
Format avec lequel afficher les traces. Les valeurs acceptables sont « par défaut », « brief » et
'verbeux'. `brief' produit des traces qui fonctionnent bien avec le GUD d'Emacs.

--répertoire-temp annuaire
AVERTISSEMENT : n'utilisez cette option que si vous savez ce que vous faites. Par défaut,
trial crée un répertoire appelé _trial_temp sous le répertoire de travail actuel.
Lors de l'essai, il s'agit d'abord suppressions ce répertoire, puis le crée, puis modifie
dans le répertoire pour exécuter les tests. Le fichier journal et tous les fichiers de couverture sont stockés
ici. Utilisez cette option si vous souhaitez faire un essai dans un répertoire autre que
_trial_temp. Soyez prévenu, le procès sera delete le répertoire avant de le recréer.

--module de test nom de fichier
Demandez au procès d'examiner nom de fichier et exécutez tous les tests spécifiés en utilisant le style Emacs
variable de tampon `test-case-name'.

--avertissements non nettoyés
À partir de Twisted 8.0, l'essai rapportera une erreur si le réacteur est laissé sale au
fin de l'épreuve. Cette option est fournie pour faciliter la migration de Twisted 2.5 vers
Twisted 8.0 et versions ultérieures. L'activation de cette option transformera les erreurs en avertissements.

-u, --jusqu'à l'échec
Continuez à boucler les tests jusqu'à ce que l'un d'entre eux lève une erreur ou un échec. C'est
particulièrement utile pour reproduire des pannes intermittentes.

--version
Imprime le numéro de version de Twisted et quitte.

--sans-module noms de modules
Simuler l'absence de la liste de modules séparés par des virgules. Cela fait
donner l'impression que les modules ne sont pas présents dans le système, ce qui entraîne des tests pour vérifier le
comportement pour cette configuration.

-z, --Aléatoire seed
Exécutez les tests dans un ordre aléatoire en utilisant la graine spécifiée. Ne passez pas cette option si
vous passez également --order.

Utilisez l'essai en ligne en utilisant les services onworks.net