Scripts bash de test unitaire

Nous avons un système qui a des scripts bash en plus du code Java. Puisque nous essayons de tester tout ce qui pourrait éventuellement casser, et que ces scripts bash peuvent casser, nous voulons les tester.

Le problème est qu'il est difficile de tester les scripts bash.

Existe-t-il un moyen ou une meilleure pratique pour tester les scripts bash? Ou devrions-nous cesser d'utiliser des scripts bash et rechercher des solutions alternatives testables?

Il existe en fait un shunit2 , un framework de test unitaire basé sur xUnit pour les scripts shell basés sur Bourne. Je ne l'ai pas utilisé moi-même, mais cela vaut peut-être la peine d'être vérifié.

Des questions similaires ont déjà été posées:

• Test unitaire pour les scripts Shell
• Tester le protocole Anything dans les scripts Shell

J'ai obtenu la réponse suivante d'un groupe de discussion:

il est possible d'importer (inclure, peu importe) une procédure (fonction, quel que soit son nom) à partir d'un fichier externe. C'est la clé de l'écriture d'un script de test: vous divisez votre script en procédures indépendantes qui peuvent ensuite être importées à la fois dans votre script en cours d'exécution et dans votre script de test, puis vous avez votre script en cours d'exécution aussi simple que possible.

Cette méthode ressemble à l'injection de dépendances pour les scripts et semble raisonnable. Il est préférable d'éviter les scripts bash et d'utiliser un langage plus testable et moins obscur.

Test Bash conforme au TAP : système de test automatisé Bash

TAP, le protocole Test Anything, est une interface textuelle simple entre les modules de test d'un faisceau de test. TAP a commencé sa vie dans le cadre du harnais de test pour Perl, mais a maintenant des implémentations en C, C ++, Python, PHP, Perl, Java, JavaScript et autres.

chauves-souris

Nikita Sobolev a écrit un excellent article de blog comparant quelques frameworks de test bash différents: Test des applications Bash

Pour les impatients: la conclusion de Nikita était d'utiliser Bats mais il semble que Nikita a raté le projet Bats-core qui me semble être celui à utiliser à l'avenir car le projet Bats original n'a pas été activement maintenu depuis 2013.

Epoxy est un framework de test Bash que j'ai conçu principalement pour tester d'autres logiciels, mais je l'utilise également pour tester des modules bash, y compris lui - même et Carton .

Les principaux avantages sont une surcharge de codage relativement faible, une imbrication d'assertions illimitée et une sélection flexible d'assertions à vérifier.

J'ai fait une présentation en le comparant à BeakerLib - un framework utilisé par certains chez Red Hat.

Pourquoi dites-vous qu'il est "difficile" de tester les scripts bash?

Quel est le problème avec les wrappers de test comme:

 #!/bin/bash
 set -e
 errors=0
 results=$($script_under_test $args<<ENDTSTDATA
 # inputs
 # go
 # here
 #
 ENDTSTDATA
 )
 [ "$?" -ne 0 ] || {
     echo "Test returned error code $?" 2>&1
     let errors+=1
     }

 echo "$results" | grep -q $expected1 || {
      echo "Test Failed.  Expected $expected1"
      let errors+=1
 }
 # and so on, et cetera, ad infinitum, ad nauseum
 [ "$errors" -gt 0 ] && {
      echo "There were $errors errors found"
      exit 1
 }

J'ai créé shellspec parce que je voulais un outil facile à utiliser et utile.

Il a été écrit par un script shell POSIX pur. Il a testé avec de nombreux obus plus que shunit2. Il a des fonctionnalités puissantes que les chauves-souris / chauves-souris.

Par exemple, prise en charge du bloc imbriqué, facile à simuler / stub, facile à ignorer / en attente, tests paramétrés, numéro de ligne d'assertion, exécution par numéro de ligne, exécution parallèle, exécution aléatoire, formateur TAP / JUnit, couverture et intégration CI, profileur, etc. .

Voir la démo sur la page du projet.

• https://github.com/shellspec/shellspec
• https://shellspec.info/

J'aime assez shell2junit , un utilitaire pour générer une sortie de type JUnit à partir de tests de script Bash. Ceci est utile car le rapport généré peut ensuite être lu par des systèmes d'intégration continue, tels que les plug-ins JUnit pour Jenkins et Bamboo.

Bien que shell2junit ne fournisse pas le cadre de script Bash complet comme shunit2 , il vous permet d'avoir de bons rapports sur les résultats des tests.

Essayez bashtest . C'est un moyen simple de tester vos scripts. Par exemple, vous avez do-some-work.shqui modifie certains fichiers de configuration. Par exemple, ajoutez une nouvelle ligne PASSWORD = 'XXXXX'au fichier de configuration /etc/my.cfg.

Vous écrivez des commandes bash ligne par ligne, puis vérifiez la sortie.

Installer:

pip3 install bashtest

Créer des tests est une simple écriture de commandes bash.

Fichier test-do-some-work.bashtest:

# run the script  
$ ./do-some-work.sh > /dev/null

# testing that the line "PASSWORD = 'XXXXX'" is in the file /etc/my.cfg   
$ grep -Fxq "PASSWORD = 'XXXXX'" /etc/my.cfg && echo "YES"
YES

Exécutez les tests:

bashtest *.bashtest

Vous pouvez trouver quelques exemples ici et ici

Peut-être que cela peut être utilisé ou contribué à

https://thorsteinssonh.github.io/bash_test_tools/

Destiné à écrire des résultats dans le protocole TAP qui, j'imagine, est bon pour CI, et bon pour ceux qui veulent des environnements shell. J'imagine que certaines choses fonctionnent dans des environnements shell, donc certains pourraient dire qu'ils devraient être testés dans leur environnement shell.

Essayez d' assert.sh

source "./assert.sh"

local expected actual
expected="Hello"
actual="World!"
assert_eq "$expected" "$actual" "not equivalent!"
# => x Hello == World :: not equivalent!

J'espère que ça aide!

Je ne peux pas croire que personne ne parle d' OSHT ! Il est compatible avec les deux TAP et JUnit, il est shell pur (qui est, pas d' autres langues concernées), il fonctionne de façon autonome aussi, et il est simple et direct.

Le test ressemble à ceci (extraits tirés de la page du projet):

#!/bin/bash
. osht.sh

# Optionally, indicate number of tests to safeguard against abnormal exits
PLAN 13

# Comparing stuff
IS $(whoami) != root
var="foobar"
IS "$var" =~ foo
ISNT "$var" == foo

# test(1)-based tests
OK -f /etc/passwd
NOK -w /etc/passwd

# Running stuff
# Check exit code
RUNS true
NRUNS false

# Check stdio/stdout/stderr
RUNS echo -e 'foo\nbar\nbaz'
GREP bar
OGREP bar
NEGREP . # verify empty

# diff output
DIFF <<EOF
foo
bar
baz
EOF

# TODO and SKIP
TODO RUNS false
SKIP test $(uname -s) == Darwin

Une course simple:

$ bash test.sh
1..13
ok 1 - IS $(whoami) != root
ok 2 - IS "$var" =~ foo
ok 3 - ISNT "$var" == foo
ok 4 - OK -f /etc/passwd
ok 5 - NOK -w /etc/passwd
ok 6 - RUNS true
ok 7 - NRUNS false
ok 8 - RUNS echo -e 'foo\nbar\nbaz'
ok 9 - GREP bar
ok 10 - OGREP bar
ok 11 - NEGREP . # verify empty
ok 12 - DIFF <<EOF
not ok 13 - TODO RUNS false # TODO Test Know to fail

Le dernier test indique "pas ok", mais le code de sortie est 0 car c'est un TODO. On peut également définir verbose:

$ OSHT_VERBOSE=1 bash test.sh # Or -v
1..13
# dcsobral \!= root
ok 1 - IS $(whoami) != root
# foobar =\~ foo
ok 2 - IS "$var" =~ foo
# \! foobar == foo
ok 3 - ISNT "$var" == foo
# test -f /etc/passwd
ok 4 - OK -f /etc/passwd
# test \! -w /etc/passwd
ok 5 - NOK -w /etc/passwd
# RUNNING: true
# STATUS: 0
# STDIO <<EOM
# EOM
ok 6 - RUNS true
# RUNNING: false
# STATUS: 1
# STDIO <<EOM
# EOM
ok 7 - NRUNS false
# RUNNING: echo -e foo\\nbar\\nbaz
# STATUS: 0
# STDIO <<EOM
# foo
# bar
# baz
# EOM
ok 8 - RUNS echo -e 'foo\nbar\nbaz'
# grep -q bar
ok 9 - GREP bar
# grep -q bar
ok 10 - OGREP bar
# \! grep -q .
ok 11 - NEGREP . # verify empty
ok 12 - DIFF <<EOF
# RUNNING: false
# STATUS: 1
# STDIO <<EOM
# EOM
not ok 13 - TODO RUNS false # TODO Test Know to fail

Renommez-le pour utiliser une .textension et placez-le dans un tsous - répertoire, et vous pouvez utiliser prove(1)(une partie de Perl) pour l'exécuter:

$ prove
t/test.t .. ok
All tests successful.
Files=1, Tests=13,  0 wallclock secs ( 0.03 usr  0.01 sys +  0.11 cusr  0.16 csys =  0.31 CPU)
Result: PASS

Définir OSHT_JUNITou transmettre -jpour produire une sortie JUnit. JUnit peut également être combiné avec prove(1).

J'ai utilisé cette bibliothèque à la fois pour tester les fonctions en recherchant leurs fichiers, puis en exécutant des assertions avec IS/ OKet leurs négatifs, et des scripts en utilisant RUN/ NRUN. Pour moi, ce cadre offre le plus de gain pour le moins de frais généraux.

J'ai essayé beaucoup de solutions présentées ici, mais j'ai trouvé la plupart d'entre elles encombrantes et difficiles à utiliser, j'ai donc créé mon propre petit cadre de test: https://github.com/meonlol/t-bash

C'est juste un fichier dans le dépôt que vous pouvez simplement exécuter directement, avec un ensemble de base d'assertions de style JUnit.

Je l'ai utilisé professionnellement dans plusieurs projets internes et j'ai pu rendre nos scripts bash super stables et résistants à la régression.

Vous voudrez peut-être jeter un œil à bash_unit:

https://github.com/pgrange/bash_unit

Jetez un œil à Outthentic , il est simple, extensible par de nombreux langages (Perl, Python, Ruby, Bash au choix) et un framework multiplateforme (Linux, Windows) pour tester toutes les applications en ligne de commande.

J'ai eu du mal à justifier l'utilisation de bash pour des scripts plus volumineux lorsque Python présente d'énormes avantages:

• Try / Except permet d'écrire des scripts plus robustes avec la possibilité d'annuler les modifications en cas d'erreur.
• Vous n'êtes pas obligé d'utiliser une syntaxe obscure telle que « if [ x"$foo" = x"$bar"]; then ...» qui est sujette à des erreurs.
• Analyse facile des options et des arguments à l'aide du getoptmodule (et il existe un module encore plus simple pour analyser les arguments, mais le nom m'échappe).
• Python vous permet de travailler avec des listes / dictées et des objets au lieu de chaînes de base et de tableaux.
• Accès aux outils de langage appropriés tels que les expressions régulières, les bases de données (bien sûr, vous pouvez tout mysqldiriger vers la commande dans bash, mais ce n'est pas la meilleure façon d'écrire du code).
• Pas besoin de s'inquiéter de l'utilisation de la forme correcte de $*ou "$*"ou "$@"ou $1ou "$1", les espaces dans les noms de fichiers ne sont pas un problème, etc., etc., etc.

Maintenant, je n'utilise bash que pour le plus simple des scripts.