Как эффективно тестировать Bash-скрипты

Bash-скрипты часто работают с файлами, сервисами, развертываниями и производственными данными. Эффективное тестирование Bash-скриптов помогает выявить ошибочные предположения до того, как задача очистки удалит не ту директорию или скрипт развертывания пропустит неудачную команду.

Вам не нужен огромный фреймворк для начала. Комбинируйте защитные опции оболочки, статические проверки, целенаправленные модульные тесты и временные тестовые окружения, чтобы ваши скрипты завершались с ошибкой громко и предсказуемо.

Основы: защитное программирование и отладка

Перед внедрением формальных модульных тестов первый уровень защиты от ошибок лежит в самой структуре скрипта. Использование строгих настроек выполнения может помочь превратить скрытые ошибки времени выполнения в немедленные сбои, что упрощает их отладку.

Необходимый защитный заголовок

Многие производственные Bash-скрипты начинаются с более строгих опций:

#!/bin/bash
# Немедленно завершить работу, если команда завершилась с ненулевым статусом.
set -e

# Считать неопределенные переменные ошибкой при подстановке.
set -u

# Предотвратить маскировку ошибок в конвейере.
set -o pipefail

Объединение их в set -euo pipefail является распространенной практикой. Имейте в виду, что set -e имеет пограничные случаи в условных конструкциях, подстановках и конвейерах, поэтому все равно явно проверяйте ожидаемые сбои, а не предполагайте, что строгий режим заменяет тесты.

Ручная отладка с помощью трассировки

Для быстрой отладки или понимания потока выполнения скрипта Bash предоставляет встроенные возможности трассировки:

Трассировка команд (-x): Выводит команды и их аргументы по мере выполнения, с префиксом +.
Без выполнения (-n): Читает команды, но не выполняет их (полезно для проверки синтаксических ошибок).

Вы можете включить трассировку как при запуске скрипта, так и внутри самого скрипта:

# Запуск скрипта с трассировкой
bash -x ./my_script.sh

# Включение трассировки внутри скрипта для определенного раздела
echo "Начало сложной операции..."
set -x # Включить трассировку
complex_function_call arg1 arg2
set +x # Отключить трассировку
echo "Операция завершена."

Внедрение формальных фреймворков модульного тестирования

Ручная отладка неустойчива для сложной логики. Формальные фреймворки модульного тестирования позволяют определять повторяемые тестовые случаи, проверять ожидаемые результаты и автоматизировать процесс валидации.

1. Bats (Bash Automated Testing System)

Bats, пожалуй, самый популярный и простой фреймворк для тестирования Bash. Он позволяет писать тесты, используя знакомый синтаксис Bash, делая утверждения простыми и читаемыми.

Ключевые особенности Bats:

Тесты пишутся с синтаксисом, похожим на Bash.
Использует простую команду run для выполнения целевого скрипта/функции.
Предоставляет встроенные переменные для утверждений, такие как $status, $output и $lines.

Пример: Тестирование простой функции

Представьте, что у вас есть скрипт (calculator.sh), содержащий функцию calculate_sum.

Фрагмент calculator.sh:

calculate_sum() {
  if [[ $# -ne 2 ]]; then
    echo "Ошибка: Требуется два аргумента" >&2
    return 1
  fi
  echo $(( $1 + $2 ))
}

test/calculator.bats:

#!/usr/bin/env bats

# Подключить скрипт, содержащий тестируемые функции.
# BATS_TEST_DIRNAME указывает на каталог, содержащий этот тестовый файл.
source "$BATS_TEST_DIRNAME/../calculator.sh"

@test "Корректные входные данные должны возвращать правильную сумму" {
  run calculate_sum 10 5
  # Проверить, что функция вернула статус успеха (0)
  [ "$status" -eq 0 ]
  # Проверить, что вывод соответствует ожиданию
  [ "$output" = "15" ]
}

@test "Отсутствующие входные данные должны возвращать статус ошибки (1)" {
  run calculate_sum 5
  [ "$status" -ne 0 ]
  [ "$status" -eq 1 ]
  # В последних версиях bats-core stderr доступен при использовании `run`.
  # [ "$stderr" = "Ошибка: Требуется два аргумента" ] 
}

Для запуска тестов:

bats test/calculator.bats

2. ShUnit2

ShUnit2 следует стилю тестирования xUnit, что делает его знакомым для разработчиков, пришедших из таких языков, как Python или Java. Он требует подключения файлов фреймворка и придерживается строгих соглашений об именовании (setUp, tearDown, test_...).

Ключевые особенности ShUnit2:

Поддерживает процедуры настройки и очистки.
Предоставляет богатый набор встроенных функций утверждений (например, assertTrue, assertEquals).

Структура ShUnit2

#!/bin/bash
# Подключить shUnit2. Настройте этот путь для вашей установки.
. /usr/local/share/shunit2/shunit2

# Определить переменные/фикстуры

setUp() {
  # Код, выполняемый перед каждым тестом
  TEMP_FILE=$(mktemp)
}

tearDown() {
  # Код, выполняемый после каждого теста (очистка)
  rm -f "$TEMP_FILE"
}

test_basic_addition() {
  local result
  # Вызвать тестируемую функцию
  result=$(my_script_function 1 2)
  
  # Использовать функцию утверждения
  assertEquals "3" "$result"
}

# Если ваш пакет shUnit2 ожидает явного подключения в конце,
# подключите его после ваших тестовых функций, а не в начале.

Лучшие практики тестирования Bash-скриптов

Эффективное тестирование выходит за рамки запуска фреймворка; оно требует тщательной изоляции компонентов и управления зависимостями окружения.

1. Обработка ввода, вывода и ошибок

Ваши тесты должны проверять стандартные потоки (stdout, stderr) и конечный код возврата, который является основным механизмом сигнализации об успехе или неудаче в Bash.

Коды возврата: Проверяйте status -eq 0 для успеха и ненулевые значения для условий ошибки, таких как ошибка парсинга или отсутствие файла.
Стандартный вывод (stdout): Обычно это основной вывод данных. Используйте $output в Bats или захватывайте вывод в ShUnit2 для проверки корректности.
Стандартный поток ошибок (stderr): Ошибки, предупреждения и отладочные сообщения должны направляться сюда. Критически важно, чтобы производственные скрипты были молчаливы в stderr при успешном выполнении.

2. Изоляция зависимостей (Мокинг)

Модульные тесты должны тестировать ваш код, а не внешние системные инструменты (такие как curl, kubectl или git). Если ваш скрипт полагается на внешнюю команду, вы должны замокать эту команду во время тестирования.

Метод: Создайте временный каталог, содержащий исполняемые файлы-заглушки с теми же именами, что и реальные зависимости. Добавьте этот каталог в начало вашего $PATH перед запуском теста, чтобы ваш скрипт вызывал заглушку вместо реального инструмента.

Пример заглушки:

#!/bin/bash
# Файл: /tmp/mock_bin/curl

if [[ "$1" == "--version" ]]; then
  echo "Mock Curl 7.6"
  exit 0
else
  # Симулировать успешный ответ API
  echo '{"status": "ok"}'
  exit 0
fi

В настройке вашего теста:

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

3. Интеграционное тестирование с временными окружениями

Интеграционные тесты проверяют, что скрипт правильно взаимодействует с файловой системой и операционной системой. Используйте временные каталоги, чтобы избежать загрязнения системы или помех другим тестам.

Использование `mktemp`

Команда mktemp -d создает безопасный уникальный временный каталог. Вы должны выполнять все манипуляции с файлами (создание, изменение, очистку) в этом каталоге во время выполнения теста.

setUp() {
  # Создать временный каталог для этого запуска теста
  TEST_ROOT=$(mktemp -d)
  cd "$TEST_ROOT"
}

tearDown() {
  # Очистить временный каталог
  cd - >/dev/null
  rm -rf "$TEST_ROOT"
}

@test "Скрипт должен создать требуемый файл журнала" {
  run my_script_that_writes_logs
  
  # Проверить, что ожидаемый файл существует во временном каталоге
  [ -f "./log/script.log" ]
}

4. Тестирование переносимости

Реализации Bash незначительно различаются (например, GNU Bash против macOS/BSD Bash). Если переносимость важна, запускайте свой набор тестов в различных целевых окружениях (например, с использованием Docker-контейнеров), чтобы выявить тонкие различия в командах утилит или подстановке параметров.

Интеграция тестирования в рабочий процесс

Тестирование не должно быть запоздалой мыслью. Включите свой набор тестов в систему контроля версий и конвейер CI/CD (непрерывная интеграция/непрерывное развертывание).

Контроль версий: Храните каталог тестов (например, test/) рядом с исходными скриптами.
Pre-Commit хуки: Используйте такие инструменты, как shellcheck (инструмент статического анализа) и форматтеры, чтобы обеспечить качество кода перед коммитами.
CI-автоматизация: Настройте ваш CI-сервер (GitHub Actions, GitLab CI, Jenkins) на автоматическое выполнение набора тестов Bats или ShUnit2 при каждом пуше. Завершайте сборку ошибкой, если любой тест возвращает ненулевой статус.

Предупреждение: Инструменты статического анализа, такие как shellcheck, являются отличными компаньонами для модульного тестирования. Они выявляют распространенные ошибки, проблемы переносимости и уязвимости безопасности, которые тесты могут пропустить. Всегда запускайте shellcheck как часть вашей рутинной предварительной проверки.

Заключение

Начните с shellcheck и set -euo pipefail, затем добавьте тесты вокруг тех частей вашего скрипта, которые разбирают ввод, выбирают файлы, вызывают внешние инструменты или вносят необратимые изменения. Небольшого набора Bats с замоканными зависимостями и временными каталогами часто достаточно, чтобы превратить рискованный скрипт в автоматизацию, которую вы можете изменять с уверенностью.