prouver - En ligne dans le Cloud

PROGRAMME:

Nom

prouver - Exécuter des tests via un harnais TAP.

UTILISATION

prouver [options] [fichiers ou répertoires]

OPTIONS

Options booléennes :

-v, --verbose Affiche toutes les lignes de test.
-l, --lib Ajoutez 'lib' au chemin de vos tests (-Ilib).
-b, --blib Ajouter 'blib/lib' et 'blib/arch' au chemin pour
vos essais
-s, --shuffle Exécute les tests dans un ordre aléatoire.
-c, --color Sortie de test colorée (par défaut).
--nocolor Ne pas colorer la sortie de test.
--count Affiche le nombre de tests X/Y lorsqu'il n'est pas verbeux
(Par défaut)
--nocount Désactive le nombre de tests X/Y.
-D --dry Essai à sec. Afficher le test qui aurait été exécuté.
-f, --failures Affiche les tests ayant échoué.
-o, --comments Afficher les commentaires.
--ignore-exit Ignore l'état de sortie des scripts de test.
-m, --merge Fusionner le STDERR des scripts de test avec leur STDOUT.
-r, --recurse Descente récursivement dans les répertoires.
--reverse Exécute les tests dans l'ordre inverse.
-q, --quiet Supprime certaines sorties de test lors de l'exécution des tests.
-Q, --QUIET N'imprime que les résultats récapitulatifs.
-p, --parse Affiche la liste complète des erreurs d'analyse TAP, le cas échéant.
--directives Afficher uniquement les résultats avec les directives TODO ou SKIP.
--timer Affiche le temps écoulé après chaque test.
--trap Trappe Ctrl-C et affiche le résumé en cas d'interruption.
--normalize Normalise la sortie TAP dans la sortie détaillée
-T Activer les contrôles d'altération.
-t Activer les avertissements d'altération.
-W Activer les avertissements fatals.
-w Activer les avertissements.
-h, --help Afficher cette aide
-?, Afficher cette aide
-V, --version Affiche la version
-H, --man Plus longue page de manuel pour prouver
--norc Ne traite pas le .proverc par défaut

Options qui prennent des arguments :

-I Chemins de bibliothèque à inclure.
-P Load plugin (recherche App::Prove::Plugin::*.)
-M Charge un module.
-e, --exec Interpréteur pour exécuter les tests ('' pour compilé
essais.)
--ext Définit l'extension pour les tests (par défaut '.t')
--harness Définit le harnais de test à utiliser. Voir TAP::Harnais.
--formatter Formateur de résultats à utiliser. Voir FORMATEURS.
--source Charger et/ou configurer un SourceHandler. Voir
GESTIONNAIRES DE SOURCES.
-a, --archive out.tgz Stocke le TAP résultant dans un fichier d'archive.
-j, --jobs N Exécuter N tâches de test en parallèle (essayez 9.)
--state=opts Contrôle l'état persistant de la preuve.
--rc=rcfile Traiter les options du fichier rc
--rules Règles pour le traitement parallèle vs séquentiel.

NOTES

.proverc
If ~/.proverc or ./.provinc existent, ils seront lus et toutes les options qu'ils contiennent seront traitées
avant les options de la ligne de commande. Options dans .proverc sont spécifiés de la même manière que
options de ligne de commande :

# .provinc
--state=chaud,rapide,sauvegarder
-j9

Des fichiers d'options supplémentaires peuvent être spécifiés avec l'option "--rc". Fichier d'options par défaut
le traitement est désactivé par l'option "--norc".

Sous Windows et VMS, le fichier d'options est nommé _provence plutôt que .proverc et est recherché
uniquement dans le répertoire courant.

en cours grâce au " STDIN "
Si vous avez une liste de tests (ou d'URL, ou tout autre élément que vous souhaitez tester) dans un fichier, vous
pouvez les ajouter à vos tests en utilisant un '-' :

prouver - < my_list_of_things_to_test.txt

Voir le "README" dans le répertoire "examples" de cette distribution.

Réglage par défaut Le test Annuaire
Si aucun fichier ou répertoire n'est fourni, "prove" recherche tous les fichiers correspondant au modèle
"t/*.t".

Coordonnez vos Le test Sortie
Sortie de test colorée à l'aide de TAP::Formatter::Color est la valeur par défaut, mais si la sortie n'est pas vers un
terminal, la couleur est désactivée. Vous pouvez remplacer cela en ajoutant le commutateur "--color".

La prise en charge des couleurs nécessite Term::ANSICor sur les plates-formes de type Unix et Win32::Console sur
les fenêtres. Si le module nécessaire n'est pas installé, la sortie couleur ne sera pas disponible.

Sortie Code
Si les tests échouent, "prove" se terminera avec un statut différent de zéro.

Arguments à Tests
Il est possible de fournir des arguments aux tests. Pour ce faire, séparez-les des siens
arguments avec l'arisdottle, '::'. Par exemple

prouver -vt/mytest.t :: --url http://example.com

courrait t/montest.t avec les options '--url http://example.com'. Lors de l'exécution de plusieurs
tests, ils recevront chacun les mêmes arguments.

"--exec"
Normalement, vous pouvez simplement passer une liste de tests Perl et le harnais saura comment exécuter
eux. Cependant, si vos tests ne sont pas écrits en Perl ou si vous voulez que tous les tests soient invoqués
exactement de la même manière, utilisez le commutateur "-e" ou "--exec":

prouver --exec '/ usr / bin / ruby -w' t/
prouver --exec '/usr/bin/perl -Tw -mstrict -Ilib' t/
prouver --exec '/chemin/vers/mon/client/exec'

"--fusionner"
Si vous devez vous assurer que vos diagnostics sont affichés dans le bon ordre par rapport à
résultats du test, vous pouvez utiliser l'option "--merge" pour fusionner le STDERR des scripts de test dans leur
STDOUT.

Cela garantit que STDOUT (où apparaissent les résultats du test) et STDERR (où le
diagnostics apparaissent) resteront synchronisés. Le harnais affichera tous les diagnostics de vos tests
émettre sur STDERR.

Attention : c'est un peu maladroit. En particulier, notez que si quelque chose qui apparaît sur
STDERR ressemble à un résultat de test, le harnais de test sera confus. Utilisez cette option uniquement
si vous comprenez les conséquences et pouvez vivre avec le risque.

"--piéger"
L'option "--trap" tentera de piéger SIGINT (Ctrl-C) lors d'un test et affichera le
résumé du test même si l'exécution est interrompue

"--Etat"
Vous pouvez demander « prove » pour se souvenir de l'état des tests précédents et sélectionner et/ou commander
les tests à exécuter en fonction de cet état enregistré.

Le commutateur "--state" requiert un argument qui doit être une liste séparée par des virgules d'un ou
plusieurs des options suivantes.

"dernier"
Exécutez les mêmes tests que la dernière fois que l'état a été enregistré. Cela permet, pour
exemple, pour recréer l'ordre d'un test mélangé.

# Exécutez tous les tests dans un ordre aléatoire
$ prouver -b --state=save --shuffle

# Exécutez-les à nouveau dans le même ordre
$ prouver -b --state=last

"échoué"
Exécutez uniquement les tests qui ont échoué lors de la dernière exécution.

# Exécuter tous les tests
$ prouver -b --state=save

# Échecs d'exécution
$ prouver -b --state=failed

Si vous spécifiez également l'option "enregistrer", les nouveaux tests réussis seront exclus de
courses suivantes.

# Répétez jusqu'à ce qu'il n'y ait plus d'échecs
$ prouver -b --state=failed,save

"passé"
Exécutez uniquement les tests réussis de la dernière fois. Utile pour s'assurer qu'aucun nouveau problème
ont été introduits.

"tous"
Exécutez tous les tests dans l'ordre normal. Plusieurs options peuvent être spécifiées, donc pour exécuter tous les tests
avec les échecs de la dernière fois en premier :

$ prouver -b --state=failed,all,save

"chaud"
Exécutez en premier les tests qui ont échoué le plus récemment. Le dernier temps d'échec de chaque test est
stocké. L'option « hot » entraîne l'exécution des tests dans l'ordre des échecs les plus récents.

$ prouver -b --state=hot,save

Les tests qui n'ont jamais échoué ne seront pas sélectionnés. Pour exécuter tous les tests avec le plus
échec de la première utilisation récemment

$ prouver -b --state=hot,all,save

Cette combinaison d'options peut également être spécifiée ainsi

$ prouver -b --state=adrian

"tout"
Exécutez tous les tests avec todos.

"lent"
Exécutez les tests du plus lent au plus rapide. Ceci est utile en conjonction avec le "-j"
commutateur de test parallèle pour vous assurer que vos tests les plus lents commencent à s'exécuter en premier.

$ prouver -b --state=slow -j9

"vite"
Exécutez les tests de test dans l'ordre le plus rapide au plus lent.

"Nouveau"
Exécutez les tests dans l'ordre du plus récent au plus ancien en fonction des heures de modification du test
scripts.

"vieux"
Exécutez les tests dans l'ordre du plus ancien au plus récent.

"Frais"
Exécutez les scripts de test qui ont été modifiés depuis le dernier test.

"enregistrer"
Enregistrez l'état à la sortie. L'état est stocké dans un fichier appelé .prouver (_prouver sous Windows
et VMS) dans le répertoire courant.

Le commutateur "--state" peut être utilisé plus d'une fois.

$ prouver -b --state=hot --state=all,save

--règles
L'option "--rules" est utilisée pour contrôler quels tests sont exécutés séquentiellement et lesquels sont exécutés
en parallèle, si l'option "--jobs" est spécifiée. L'option peut être spécifiée plusieurs
fois, et l'ordre compte.

L'utilisation la plus pratique est susceptible de spécifier que certains tests ne sont pas "parallel-ready".
Étant donné que la mention d'un fichier avec --rules n'entraîne pas sa sélection pour s'exécuter en tant que test, vous
pouvez "définir et oublier" certaines préférences de règles dans votre fichier .proverc. Ensuite, vous pourrez
tirer le meilleur parti des avantages en termes de performances des tests parallèles, tandis que certains
les exceptions sont toujours exécutées en parallèle.

--règles exemples

# Tous les tests sont autorisés à s'exécuter en parallèle, sauf ceux commençant par "p"
--rules='seq=t/p*.t' --rules='par=**'

# Tous les tests doivent être exécutés en séquence sauf ceux commençant par "p", qui doivent être exécutés en parallèle
--rules='par=t/p*.t'

--règles RAPIDE

· Par défaut, tous les tests peuvent être exécutés en parallèle. Spécification de l'un des vôtres
règles supprime celui-ci.

· "Le premier match gagne". La première règle qui correspond à un test sera celle qui s'applique.

· Tout test qui ne correspond pas à une règle sera exécuté en séquence à la fin de l'exécution.

· L'existence d'une règle n'implique pas la sélection d'un test. Vous devez quand même spécifier le
tests à exécuter.

· La spécification d'une règle pour autoriser les tests à s'exécuter en parallèle ne les fait pas s'exécuter dans
parallèle. Vous devez toujours spécifier le nombre de "travaux" parallèles dans votre objet Harness.

--règles Style globe modèle assorti

Nous implémentons notre propre correspondance de modèle de style glob pour --rules. Voici les supportés
modèles:

** est un nombre quelconque de caractères, y compris /, dans un chemin
* correspond à zéro ou plusieurs caractères dans un nom de fichier/répertoire
? est exactement un caractère dans un nom de fichier/répertoire
{foo,bar,baz} est n'importe lequel de foo, bar ou baz.
\ est un caractère d'échappement

Plus Avancée caractéristiques pour parallèle vs séquence courir

Si vous avez besoin d'une gestion plus avancée de ce qui s'exécute en parallèle ou en séquence, consultez le
la documentation 'règles' associée dans TAP::Harness et TAP::Parser::Scheduler. Si c'est quoi
possible directement via "prove" n'est pas suffisant, vous pouvez écrire votre propre harnais pour
accéder directement à ces fonctionnalités.

@INC
prouve introduit une séparation entre les "options passées au perl qui exécute prouve" et
"options passées au perl qui exécute les tests" ; cette distinction est intentionnelle. Ainsi, le
perl qui exécute un test démarre avec la valeur par défaut @INC. Répertoires de bibliothèque supplémentaires
peut être ajouté via la variable d'environnement "PERL5LIB", via -Ifoo dans "PERL5OPT" ou via le
Option "-Ilib" pour prouver.

Entacher Mode
Normalement, lorsqu'un programme Perl est exécuté en mode taint, le contenu du "PERL5LIB"
La variable d'environnement n'apparaît pas dans @INC.

Parce que "PERL5LIB" est souvent utilisé pendant les tests pour ajouter des répertoires de construction à @INC
passe les noms de tous les répertoires trouvés dans "PERL5LIB" en tant que commutateurs -I. L'effet net de
c'est que "PERL5LIB" est honoré même lorsque la preuve est exécutée en mode taint.

FORMATEURS

Vous pouvez charger un TAP::Parser::Formatter personnalisé :

prouver --formatter MonFormatter

SOURCE MANIPULATEURS

Vous pouvez charger des TAP::Parser::SourceHandlers personnalisés, pour changer la façon dont l'analyseur interprète
particulier sources de TAP.

prouver --source MyHandler --source YetAnother t

Si vous souhaitez fournir la configuration à la source, vous pouvez utiliser :

prouver --source MyCustom \
--source Perl --perl-option 'foo=bar baz' --perl-option moy=0.278 \
--source Fichier --file-option extensions=.txt --file-option extensions=.tmp t
--source pgTAP --pgtap-option pset=format=html --pgtap-option pset=border=2

Chaque option "--$source-option" doit spécifier une paire clé/valeur séparée par un "=". Si un
L'option peut prendre plusieurs valeurs, il suffit de la spécifier plusieurs fois, comme avec les "extensions="
exemples ci-dessus. Si l'option doit être une référence de hachage, spécifiez la valeur en tant que deuxième
paire séparée par un "=", comme dans les exemples "pset=" ci-dessus (escape "=" avec une barre oblique inverse).

Tous les "--sources" sont combinés dans un hachage et transmis à "new" dans les "sources" de TAP::Harness
paramètre.

Voir TAP::Parser::IteratorFactory pour plus de détails sur la façon dont la configuration est transmise à
Gestionnaires de sources.

PLUGINS

Les plugins peuvent être chargés en utilisant le "-Pbrancher" syntaxe, par exemple :

prouver -PMyPlugin

Cela recherchera un module nommé "App::Prove::Plugin::MyPlugin", ou à défaut,
"MonPlugin". Si le plugin est introuvable, "prove" se plaindra et se fermera.

Vous pouvez passer des arguments à votre plugin en ajoutant "=arg1,arg2,etc" au nom du plugin :

prouver -PMyPlugin=fou,du,fafa

Veuillez consulter la documentation de chaque plugin pour plus de détails.

Disponible Plugins
Pour une liste à jour des plugins disponibles, veuillez vérifier CPAN :

<http://search.cpan.org/search?query=App%3A%3APrve+Plugin>

Écriture Plugins
Veuillez voir "PLUGINS" dans App::Prove.

Utiliser prouver en ligne en utilisant les services onworks.net