Модульное тестирование сценариев bash

У нас есть система, которая имеет некоторые сценарии bash, работающие помимо Java-кода. Поскольку мы пытаемся протестировать все, что может сломаться, и эти сценарии bash могут сломаться, мы хотим их протестировать.

проблема трудно проверить скрипты bash.

есть ли способ или лучшая практика для тестирования сценариев bash? Или мы должны прекратить использовать сценарии bash и искать альтернативные решения, которые можно проверить?

87
automated-tests bash extreme-programming tdd testing

13 ответов

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

подобные вопросы задавались и раньше:

38

Я получил следующий ответ от дискуссионной группы:

можно импортировать (включая, все) процедура (функция, как бы он ни назывался) от внешнего файл. Это ключ к написанию сценарий тестирования: вы разбиваете сценарий в независимые процедуры это может быть импортировано в оба запущенный сценарий и тестирование сценарий, а затем у вас есть свой запуск скрипт должен быть максимально простым.

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

25
17

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

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

Я презентация сравнение с BeakerLib - рамки, используемые некоторыми В Red Hat.

7

почему вы говорите, что" трудно " тестировать сценарии bash?

что не так с тестовыми обертками, такими как:

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

попробовать bashtest. Это простой способ проверить свои сценарии. Например, у вас есть do-some-work.sh которые изменяют некоторые файлы конфигурации. Например, добавьте новую строку PASSWORD = 'XXXXX' в конфигурационный файл /etc/my.cfg.

вы пишете команды bash строка за строкой, а затем проверяете вывод.

установка:

pip3 install bashtest

Create tests-это просто написание команд bash.

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

выполнить тесты: 

bashtest *.bashtest

вы можете найти вот некоторые примеры и здесь

3

возможно, это можно использовать или внести вклад в

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

предназначен для записи результатов в протоколе TAP, который, как я полагаю, хорош для CI и хорош для тех, кто хочет среды оболочки. Я предполагаю, что некоторые вещи работают в средах оболочки, поэтому некоторые могут утверждать, что их следует тестировать в среде оболочки.

3

попробуйте assert.sh

source "./assert.sh"

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

надеюсь, что это помогает!

3

Никита Соболев написал отличный пост в блоге, сравнивая несколько разных тестовых фреймворков bash: тестирование приложений Bash

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

3

Мне нравится shell2junit, утилита для создания JUnit-подобных выходных данных из тестов сценариев Bash. Это полезно, потому что созданный отчет может быть прочитан системами непрерывной интеграции, такими как подключаемые модули JUnit для Jenkins и Bamboo.

пока shell2junit не обеспечивает всеобъемлющего Баш рамках сценариев, как shunit2, это позволяет вам иметь хорошую отчетность о результатах тестирования.

2

возможно, вы захотите взглянуть на bash_unit:

https://github.com/pgrange/bash_unit

0

посмотри Outthentic, это простой, расширяемый многими языками ( Perl, Python, Ruby, Bash на выбор ) и кросс-платформенный (Linux, Windows ) фреймворк для тестирования любых приложений командной строки.

0

мне было трудно оправдать использование bash для больших скриптов, когда Python имеет такие огромные преимущества:

  • Try / Except позволяет писать более надежные скрипты с возможностью отмены изменений в случае ошибки.
  • вам не нужно использовать неясный синтаксис, такой как'if [ x"$foo" = x"$bar"]; then ...', который склонен к ошибкам.
  • легкий разбор параметров и аргументов с помощью getopt module (и есть еще более простой модуль для разбора аргументов, но имя ускользает от меня).
  • язык Python позволяет работать со списками/словарь и предметы вместо обычной строки и массивы.
  • доступ к соответствующим языковым инструментам, таким как регулярное выражение, базы данных (конечно, вы можете передать все в mysql команда в bash, но это не самый лучший способ написать код).
  • не нужно беспокоиться об использовании правильной формы $* или "$*" или "$@" или или "", пробелы в именах файлов не являются проблемой и т. д., так далее.

теперь я использую bash только для самых простых скриптов.

-2