Scripts bash de teste de unidade

Temos um sistema que possui alguns scripts bash rodando além do código Java. Como estamos tentando testar tudo que pode possivelmente quebrar, e esses scripts bash podem falhar, queremos testá-los.

O problema é que é difícil testar scripts bash.

Existe uma maneira ou uma prática recomendada para testar scripts bash? Ou devemos parar de usar scripts bash e procurar soluções alternativas testáveis?

Na verdade, existe um shunit2 , uma estrutura de teste de unidade baseada em xUnit para scripts de shell baseados em Bourne. Eu não usei sozinho, mas pode valer a pena conferir.

Perguntas semelhantes já foram feitas antes:

• Teste de Unidade para Scripts Shell
• Teste Anything Protocol em Shell Scripts

Recebi a seguinte resposta de um grupo de discussão:

é possível importar (incluir, qualquer coisa) um procedimento (função, qualquer que seja o nome) de um arquivo externo. Esta é a chave para escrever um script de teste: você divide seu script em procedimentos independentes que podem ser importados tanto para o script em execução quanto para o script de teste, e então você tem o script em execução o mais simples possível.

Este método é como injeção de dependência para scripts e parece razoável. É preferível evitar scripts bash e usar uma linguagem mais testável e menos obscura.

Teste Bash compatível com TAP : Sistema de teste automatizado Bash

TAP, o Test Anything Protocol, é uma interface simples baseada em texto entre módulos de teste em um equipamento de teste. O TAP começou como parte do equipamento de teste para Perl, mas agora tem implementações em C, C ++, Python, PHP, Perl, Java, JavaScript e outros.

núcleo de morcego

Nikita Sobolev escreveu uma excelente postagem no blog comparando algumas estruturas de teste bash diferentes: Testando aplicativos Bash

Para os impacientes: a conclusão de Nikita foi usar Bats, mas parece que Nikita perdeu o projeto Bats-core , que me parece ser aquele a usar daqui para frente, já que o projeto Bats original não foi mantido ativamente desde 2013.

Epoxy é uma estrutura de teste Bash que projetei principalmente para testar outro software, mas também o uso para testar módulos bash, incluindo ele próprio e o Carton .

As principais vantagens são a sobrecarga de codificação relativamente baixa, aninhamento de asserções ilimitado e seleção flexível de asserções a serem verificadas.

Fiz uma apresentação comparando-o ao BeakerLib - um framework usado por alguns na Red Hat.

Por que você diz que é "difícil" testar scripts bash?

O que há de errado com wrappers de teste como:

 #!/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
 }

Eu criei shellspec porque queria uma ferramenta útil e fácil de usar.

Escrito por puro script de shell POSIX. Ele foi testado com muitos shells mais do que shunit2. Possui recursos poderosos do que morcegos / núcleo de morcegos.

Por exemplo, suporte a bloco aninhado, fácil de simular / stub, fácil de pular / pendente, testes parametrizados, número de linha de asserção, execução por número de linha, execução paralela, execução aleatória, formatador TAP / JUnit, cobertura e integração de CI, criador de perfil e etc .

Veja a demonstração na página do projeto.

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

Eu gosto bastante do shell2junit , um utilitário para gerar saída do tipo JUnit de testes de script Bash. Isso é útil porque o relatório gerado pode ser lido por sistemas de integração contínua, como os plug-ins JUnit para Jenkins e Bamboo.

Embora o shell2junit não forneça a estrutura de script Bash abrangente como o shunit2 , ele permite que você tenha bons relatórios dos resultados do teste.

Tente bashtest . É uma maneira simples de testar seus scripts. Por exemplo, você tem do-some-work.shque alterar alguns arquivos de configuração. Por exemplo, adicione uma nova linha PASSWORD = 'XXXXX'ao arquivo de configuração/etc/my.cfg .

Você escreve os comandos do bash linha por linha e verifica a saída.

Instalar:

pip3 install bashtest

Criar testes é apenas escrever comandos bash.

Arquivo 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

Execute testes:

bashtest *.bashtest

Você pode encontrar alguns exemplos aqui e aqui

Talvez isso possa ser usado ou contribuído para

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

Destina-se a escrever resultados em protocolo TAP que imagino ser bom para CI e bom para aqueles que desejam ambientes shell. Imagino que algumas coisas sejam executadas em ambientes de shell, portanto, alguns podem argumentar que devem ser testados em seu ambiente de shell.

Experimente assert.sh

source "./assert.sh"

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

Espero que ajude!

Não acredito que ninguém falou sobre OSHT ! É compatível com ambos TAP e JUnit, é pura shell (isto é, há outros idiomas envolvidos), ele funciona autônomo também, e é simples e direta.

O teste se parece com isto (fragmentos retirados da página do projeto):

#!/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

Uma corrida simples:

$ 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

O último teste mostra "não está ok", mas o código de saída é 0 porque é um TODO. Pode-se definir verbose também:

$ 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

Renomeie-o para usar uma .textensão e coloque-o em um tsubdiretório, e você pode usar prove(1)(parte do Perl) para executá-lo:

$ 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

Defina OSHT_JUNITou passe -jpara produzir saída JUnit. JUnit também pode ser combinado com prove(1).

Eu usei essa biblioteca tanto funções de teste, fornecendo seus arquivos e, em seguida, executando assertions com IS/ OKe seus negativos, quanto scripts usando RUN/ NRUN. Para mim, essa estrutura fornece mais ganho com o mínimo de sobrecarga.

Tentei muitas das soluções apresentadas aqui, mas achei a maioria delas muito volumosas e difíceis de usar, então criei minha própria pequena estrutura de teste: https://github.com/meonlol/t-bash

É apenas um arquivo no repo que você pode simplesmente executar diretamente, com um conjunto básico de declarações de estilo JUnit.

Usei-o profissionalmente em vários projetos internos e fui capaz de tornar nossos scripts bash superestáveis ​​e resistentes a regressões.

Você pode querer dar uma olhada em bash_unit:

https://github.com/pgrange/bash_unit

Dê uma olhada no Outthentic , é simples, extensível por várias linguagens (Perl, Python, Ruby, Bash na escolha) e plataforma cruzada (Linux, Windows) para testar qualquer aplicação de linha de comando.

Achei difícil justificar o uso do bash para scripts maiores quando o Python tem grandes vantagens:

• Try / Except permite escrever scripts mais robustos com a capacidade de desfazer alterações em caso de erro.
• Você não precisa usar uma sintaxe obscura como ' if [ x"$foo" = x"$bar"]; then ...', que está sujeita a erros.
• Análise fácil de opções e argumentos usando o getoptmódulo (e há um módulo ainda mais fácil para análise de argumentos, mas o nome me escapa).
• Python permite que você trabalhe com listas / dicts e objetos em vez de strings e arrays básicos.
• Acesso a ferramentas de linguagem adequadas, como regex, bancos de dados (claro, você pode canalizar tudo para o mysqlcomando no bash, mas não é a maneira mais agradável de escrever código).
• Não precisa se preocupar em usar a forma correta de $*ou "$*"ou "$@"ou $1ou "$1", os espaços nos nomes dos arquivos não são um problema, etc, etc, etc.

Agora eu uso o bash apenas para os scripts mais simples.