tesh - En ligne dans le Cloud

PROGRAMME:

Nom

tesh - shell de test

SYNOPSIS

teste [OPTION]... [DOSSIER] ...

DESCRIPTION

C'est l'outil TESH. Il constitue un shell de test, c'est-à-dire une sorte de shell spécialisé
exécuter des tests. La liste des actions à entreprendre est analysée à partir de fichiers nommés testsuite.

OPTIONS

--cd some/directory : demande à tesh de changer de répertoire de travail avant
lancer les tests
--setenv var=value : définit une variable d'environnement spécifique
--cfg arg : ajoute le paramètre --cfg=arg à chaque ligne de commande
--enable-coverage : ignore les lignes de sortie commençant par "profiling:"

TESTER DOSSIER SYNTAXE

Voici la syntaxe de ces fichiers :

Le type de chaque ligne est donné par le premier caractère (le deuxième caractère doit être vide et est
ignoré):

Commande `$' à exécuter au premier plan
`&' commande à exécuter en arrière-plan
`<' entrée à passer à la commande
`>' sortie attendue de la commande
`!' métacommande, qui peut être l'une des suivantes :
'timeout' |non
's'attendre à un signal'
" s'attendre à un retour "
"sortie"
`setenv = '
`p' une chaîne à imprimer
`P' une chaîne à imprimer au niveau CRITIQUE (facilité de journalisation)

Si la sortie attendue ne correspond pas à ce que la commande crache, TESH produira une erreur
montrant le diff (voir OUTPUT ci-dessous).

IO COMMANDES

Les lignes < et > ajoutent IO à la commande définie dans le bloc courant (les blocs sont séparés
par des lignes vides). Il est possible de placer ces lignes soit après la commande, soit avant.
La différence entre les deux morceaux suivants est principalement cosmétique dans vos suites de test,
TESH s'en moque. (cf IO-orders.tesh)

$ chat
< TOTO
> TOTO

> TOTO
$ chat
< TOTO

Néanmoins, il est possible d'avoir plusieurs commandes dans le même bloc, mais aucune
peut avoir n'importe quelle sortie. Cela peut sembler un peu restrictif, car on pourrait dire qu'une commande obtient
toutes les E/S jusqu'à la prochaine commande, mais j'ai peur des erreurs telles que les suivantes :

$ cd tout
> TOTO
$ mkfile fichier

TOTO sera passé à la commande cd, où l'utilisateur veut clairement le passer au
commande intégrée mkfile (voir ci-dessous).

FLUX REDIRECTION

Les redirections de flux (les constructions ">", "<" et "|" dans sh) ne sont pas encore implémentées dans tesh.
C'est un peu restrictif, mais bon, patch bienvenu...

La situation dans laquelle il est principalement problématique est de créer un fichier temporaire. Les
la solution consiste à utiliser la commande intégrée "mkfile", comme dans l'exemple suivant : $ mkfile
myFile > du contenu > dans le fichier

Cela créera un fichier appelé myFile (premier argument de la commande mkfile). Son contenu
sera toute l'entrée fournie à la commande.

RETOUR CODE

TESH crache un message d'erreur approprié lorsque les fils ne retournent pas 0 comme code retour (cf.
catch-return.tesh) et renvoie le code+40 lui-même.

Il est également possible de spécifier qu'une commande donnée doit retourner une autre valeur. Pour ça,
utilisez la métacommande "expect return", qui prend un entier comme argument. Le changement seulement
appliquer à la commande suivante (cf. set-return.tesh).

SIGNAUX

TESH détecte quand l'enfant est tué par un signal (comme sur les erreurs de segmentation) et crache un
message d'erreur approprié (cf. catch-signal.tesh).

Il est également possible de spécifier qu'une commande donnée doit élever un signal donné. Pour ça,
utilisez la métacommande « expect signal ». Il prend le nom du signal comme argument. Le changement seulement
appliquer à la commande suivante (cf. set-signal.tesh).

TEMPS MORT

Par défaut, toutes les commandes ont 5 secondes pour s'exécuter (cf. catch-timeout.tesh). Vous pouvez
changez cela avec le "timeout", qui prend un entier comme argument. Le changement s'applique uniquement
à la commande suivante (cf. set-timeout.tesh). Si vous passez "non" en argument, la commande
ne peut pas expirer.

SORTIE

Par défaut, la sortie des commandes est comparée à celle attendue, et une erreur est
soulevée en cas de divergence. Métacommandes pour changer cela :
"output ignorer" -> sortie complètement ignorée
"affichage de la sortie" -> sortie affichée (mais non vérifiée)
"sortie de sortie" -> trie l'affichage avant de le vérifier (voir ci-dessous)

TRI SORTIE

Trier la sortie semble être une idée étrange, mais c'est obligatoire dans SimGrid puisque le
les processus s'exécutent dans le désordre à n'importe quel point de planification (c'est-à-dire que tous les processus sont prêts à s'exécuter à
temps t simulé exécuté en parallèle). Pour garantir que les sorties du simulateur correspondent toujours, nous
devez trier la sortie avant de la comparer.

Nous nous attendons à ce que les simulateurs s'exécutent avec cet argument de formatage de journal :
--log=root.fmt:[%10.6r]%e(%i:%P@%h)%e%m%n Ensuite, tesh trie la chaîne sur les 19 premiers caractères
seulement, et est stable lorsque les débuts de ligne sont égaux. Cela devrait garantir que :
(1) le test est efficace (pas de faux positif, pas de faux négatif)
(2) les points de planification sont séparés les uns des autres
(3) à chaque point de planification, les processus sont séparés les uns des autres
(4) l'ordre de ce que dit un processus donné à un ordonnancement donné
point est conservé.

C'est bien sûr très orienté SimGrid, brisant la généralité de tesh, mais qu'importe,
réellement?

Si vous souhaitez modifier la longueur du préfixe utilisé pour le tri, précisez-le simplement après
la directive de tri de sortie, comme ceci :

! tri de sortie 22

ENVIRONNEMENT

Vous pouvez ajouter du contenu à l'environnement des processus testés avec la métacommande setenv.
Cela fonctionne comme prévu. Par exemple:
"setenv CHEMIN=/ bin"

Utilisez tesh en ligne en utilisant les services onworks.net