Писал ли юнит-тесты для bash-скриптов

Что проверяют

Относитесь ли вы к вспомогательным скриптам как к коду или как к черновику. Вопрос задают и разработчикам на Go, потому что вокруг сервиса всегда есть слой bash: сборка образа, миграции, запуск в контейнере, и ломается он ровно там, где его никто не проверяет.

Как отвечать

Если писали, назовите инструмент и подход. Рабочий набор: bats для тестов, shellcheck для статического анализа, shfmt для форматирования. Чтобы скрипт вообще можно было тестировать, логика выносится в функции, а точка входа прячется за проверкой, что файл запущен, а не подключён:

main() {
  deploy "$@"
}

if [[ "${BASH_SOURCE[0]}" == "${0}" ]]; then
  main "$@"
fi

Тест тогда подключает файл и зовёт функцию напрямую, а внешние команды подменяются заглушками в начале PATH.

Скажите, что проверяете: коды возврата, поведение при пустых и содержащих пробелы аргументах, идемпотентность повторного запуска. И упомяните set -euo pipefail в начале скрипта, без него выполнение молча продолжается после ошибки.

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

Где спотыкаются

Говорят «нет» и останавливаются. Ответ «юнит-тестов не писал, но гоняю shellcheck в пайплайне и проверяю скрипт на тестовом окружении» звучит совсем иначе: это позиция, а не пробел в опыте.

Второе: тестируют скрипт целиком, запуская его по-настоящему. Такой тест ходит в сеть, правит файлы и требует прав, поэтому в пайплайне он либо отключён, либо мигает через раз и ему перестают верить.

Третье: забывают кавычки вокруг переменных. Путь с пробелом или пустое значение превращают команду в другую команду, и это самый частый дефект в bash, который как раз и ловится тестом с неудобными данными.