Como Testar Seus Scripts Bash de Forma Eficaz

Scripts Bash frequentemente manipulam arquivos, serviços, implantações e dados de produção. Testar seus scripts Bash de forma eficaz ajuda a detectar suposições incorretas antes que um trabalho de limpeza remova o diretório errado ou um script de implantação ignore um comando com falha.

Você não precisa de um framework enorme para começar. Combine opções defensivas do shell, verificações estáticas, testes unitários focados e ambientes de teste temporários para que seus scripts falhem de forma ruidosa e previsível.

Fundamentos: Codificação Defensiva e Depuração

Antes de implementar testes unitários formais, a primeira camada de defesa contra bugs está na própria estrutura do script. Utilizar configurações operacionais estritas pode ajudar a transformar erros sutis de tempo de execução em falhas imediatas, facilitando a depuração.

Cabeçalho Defensivo Essencial

Muitos scripts Bash de produção começam com opções mais rigorosas:

#!/bin/bash
# Sair imediatamente se um comando sair com status não zero.
set -e

# Tratar variáveis não definidas como erro ao substituir.
set -u

# Impedir que erros em um pipeline sejam mascarados.
set -o pipefail

Combinar estes em set -euo pipefail é comum. Esteja ciente de que set -e tem casos extremos em condicionais, subshells e pipelines, portanto, ainda verifique falhas esperadas explicitamente em vez de assumir que o modo estrito substitui os testes.

Depuração Manual com Rastreamento

Para depuração rápida ou compreensão do fluxo de execução do script, o Bash oferece capacidades de rastreamento integradas:

Rastreamento de Comandos (-x): Imprime comandos e seus argumentos conforme são executados, prefixados por +.
Sem Execução (-n): Lê comandos, mas não os executa (útil para verificar erros de sintaxe).

Você pode ativar o rastreamento ao executar o script ou dentro do próprio script:

# Executando o script com rastreamento
bash -x ./meu_script.sh

# Ativando o rastreamento dentro do script para uma seção específica
echo "Iniciando operação complexa..."
set -x # Ativar rastreamento
chamada_funcao_complexa arg1 arg2
set +x # Desativar rastreamento
echo "Operação finalizada."

Adotando Frameworks Formais de Teste Unitário

A depuração manual é insustentável para lógica complexa. Frameworks formais de teste unitário permitem definir casos de teste repetíveis, afirmar resultados esperados e automatizar o processo de validação.

1. Bats (Bash Automated Testing System)

Bats é, sem dúvida, o framework mais popular e fácil para teste Bash. Ele permite escrever testes usando sintaxe Bash familiar, tornando as asserções simples e legíveis.

Principais Características do Bats:

Testes são escritos com sintaxe semelhante ao Bash.
Usa o comando simples run para executar o script/função alvo.
Fornece variáveis de asserção integradas como $status, $output e $lines.

Exemplo: Testando uma Função Simples

Imagine que você tem um script (calculadora.sh) contendo uma função calcular_soma.

Trecho de calculadora.sh:

calcular_soma() {
  if [[ $# -ne 2 ]]; then
    echo "Erro: Requer dois argumentos" >&2
    return 1
  fi
  echo $(( $1 + $2 ))
}

test/calculadora.bats:

#!/usr/bin/env bats

# Fonte do script contendo as funções a serem testadas.
# BATS_TEST_DIRNAME aponta para o diretório que contém este arquivo de teste.
source "$BATS_TEST_DIRNAME/../calculadora.sh"

@test "Entradas válidas devem retornar a soma correta" {
  run calcular_soma 10 5
  # Afirmar que a função retornou um status de sucesso (0)
  [ "$status" -eq 0 ]
  # Afirmar que a saída corresponde à expectativa
  [ "$output" = "15" ]
}

@test "Entradas faltando devem retornar status de erro (1)" {
  run calcular_soma 5
  [ "$status" -ne 0 ]
  [ "$status" -eq 1 ]
  # Em versões recentes do bats-core, stderr está disponível ao usar `run`.
  # [ "$stderr" = "Erro: Requer dois argumentos" ] 
}

Para executar os testes:

bats test/calculadora.bats

2. ShUnit2

ShUnit2 segue o estilo de teste xUnit, tornando-o familiar para desenvolvedores vindos de linguagens como Python ou Java. Requer a inclusão dos arquivos do framework e adere a uma convenção de nomenclatura estrita (setUp, tearDown, test_...).

Principais Características do ShUnit2:

Suporta rotinas de configuração e desmontagem para limpeza.
Fornece um conjunto rico de funções de asserção integradas (por exemplo, assertTrue, assertEquals).

Estrutura do ShUnit2

#!/bin/bash
# Fonte do shUnit2. Ajuste este caminho para sua instalação.
. /usr/local/share/shunit2/shunit2

# Definir variáveis/fixtures

setUp() {
  # Código a ser executado antes de cada teste
  ARQUIVO_TEMP=$(mktemp)
}

tearDown() {
  # Código a ser executado após cada teste (limpeza)
  rm -f "$ARQUIVO_TEMP"
}

teste_adicao_basica() {
  local resultado
  # Chamar a função sendo testada
  resultado=$(minha_funcao_script 1 2)
  
  # Usar uma função de asserção
  assertEquals "3" "$resultado"
}

# Se seu pacote shUnit2 espera inclusão explícita no final,
# inclua-o após suas funções de teste em vez de perto do topo.

Melhores Práticas para Teste de Scripts Bash

Testes eficazes vão além de executar um framework; requerem isolamento cuidadoso de componentes e gerenciamento de dependências ambientais.

1. Lidando com Entrada, Saída e Erros

Seus testes devem verificar streams padrão (stdout, stderr) e o código de saída final, que é o mecanismo principal para sinalizar sucesso ou falha no Bash.

Códigos de Saída: Teste status -eq 0 para sucesso e valores não zero para condições de erro, como falha de análise ou arquivos ausentes.
Saída Padrão (stdout): Esta é tipicamente a saída de dados primária. Use $output do Bats ou capture a saída no ShUnit2 para afirmar a correção.
Erro Padrão (stderr): Erros, avisos e mensagens de depuração devem ser roteados aqui. Crucialmente, garanta que scripts de produção sejam silenciosos em stderr durante execuções bem-sucedidas.

2. Isolando Dependências (Mocking)

Testes unitários devem testar seu código, não ferramentas externas do sistema (como curl, kubectl ou git). Se seu script depende de um comando externo, você deve simular esse comando durante o teste.

Método: Crie um diretório temporário contendo arquivos executáveis simulados que tenham o mesmo nome das dependências reais. Prefixe este diretório ao seu $PATH antes de executar o teste, garantindo que seu script chame o simulado em vez da ferramenta real.

Exemplo de Simulação:

#!/bin/bash
# Arquivo: /tmp/mock_bin/curl

if [[ "$1" == "--version" ]]; then
  echo "Mock Curl 7.6"
  exit 0
else
  # Simular uma resposta de API bem-sucedida
  echo '{"status": "ok"}'
  exit 0
fi

Na configuração do seu teste:

export PATH="/tmp/mock_bin:$PATH"

3. Teste de Integração com Ambientes Temporários

Testes de integração verificam se o script interage corretamente com o sistema de arquivos e o sistema operacional. Use diretórios temporários para evitar poluir o sistema ou interferir com outros testes.

Usando `mktemp`

O comando mktemp -d cria um diretório temporário seguro e único. Você deve realizar toda a manipulação de arquivos (criação, modificação, limpeza) dentro deste diretório durante a execução do teste.

setUp() {
  # Criar um diretório temporário para esta execução de teste
  RAIZ_TESTE=$(mktemp -d)
  cd "$RAIZ_TESTE"
}

tearDown() {
  # Limpar o diretório temporário
  cd - >/dev/null
  rm -rf "$RAIZ_TESTE"
}

@test "Script deve criar arquivo de log necessário" {
  run meu_script_que_escreve_logs
  
  # Afirmar que o arquivo esperado existe no diretório temporário
  [ -f "./log/script.log" ]
}

4. Testando Portabilidade

As implementações do Bash variam ligeiramente (por exemplo, GNU Bash vs. macOS/BSD Bash). Se a portabilidade for uma preocupação, execute seu conjunto de testes em vários ambientes alvo (por exemplo, usando contêineres Docker) para detectar diferenças sutis em comandos de utilitários ou expansão de parâmetros.

Integrando Testes no Fluxo de Trabalho

Testes não devem ser uma reflexão tardia. Incorpore seu conjunto de testes ao seu controle de versão e pipeline CI/CD (Integração Contínua/Implantação Contínua).

Controle de Versão: Armazene o diretório de teste (por exemplo, test/) junto com seus scripts fonte.
Hooks de Pré-Commit: Use ferramentas como shellcheck (uma ferramenta de análise estática) e formatadores para garantir a qualidade do código antes dos commits.
Automação CI: Configure seu servidor CI (GitHub Actions, GitLab CI, Jenkins) para executar o conjunto de testes Bats ou ShUnit2 automaticamente a cada push. Falhe a construção se algum teste retornar um status não zero.

Aviso: Ferramentas de análise estática como shellcheck são excelentes companheiras para testes unitários. Elas detectam erros comuns, problemas de portabilidade e vulnerabilidades de segurança que os testes podem perder. Sempre execute shellcheck como parte de sua rotina de pré-teste.

Conclusão

Comece com shellcheck e set -euo pipefail, depois adicione testes em torno das partes do seu script que analisam entrada, escolhem arquivos, chamam ferramentas externas ou fazem alterações irreversíveis. Um pequeno conjunto Bats com dependências simuladas e diretórios temporários é muitas vezes suficiente para transformar um script arriscado em automação que você pode alterar com confiança.