ShellCheck и тестирование скриптов — бесплатный тест онлайн

Вопрос 1 из 30

В служебном сценарии найден следующий фрагмент по теме «Статический анализ». Какой вывод об этом варианте можно сделать без догадок о внешнем контексте?

files=$(find . -type f)
for f in $files; do echo "$f"; done

Подавление предупреждения не исправляет дефект и превращает осознанный риск в постоянную слепую зону. ShellCheck предупредит о разбиении вывода find, потому что имена с пробелами и переводами строк повредятся. Тест проверяет отказ и то, что незавершённый артефакт не остался как активный результат. Подстановка команд удаляет хвостовые переводы строк и может скрыть различие; для байтового сравнения лучше cmp с файлами. Точный код и сообщение связывают тест с нужной ветвью; дополнительно проверяют, что внешняя команда не была вызвана.

Вопрос 2 из 30

В служебном сценарии найден следующий фрагмент по теме «Тестирование через Bats». Какой разбор соответствует именно показанной последовательности команд?

@test "returns 64 without args" {
  run ./script.sh
  [ "$status" -eq 64 ]
}

Тест запускает сценарий без аргументов и проверяет именно код ошибки использования 64. Подавление предупреждения не исправляет дефект и превращает осознанный риск в постоянную слепую зону. Общий путь /tmp/result создаёт конфликты между параллельными тестами и может использовать старый файл от предыдущего запуска. Переписывание устраняет первопричину и сохраняет произвольные имена; ShellCheck затем проверяет соседние ошибки. Точный код и сообщение связывают тест с нужной ветвью; дополнительно проверяют, что внешняя команда не была вызвана.

Вопрос 3 из 30

В служебном сценарии найден следующий фрагмент по теме «Тестовые окружения». Какое описание не приписывает фрагменту лишних гарантий?

fakebin=$(mktemp -d)
printf '#!/bin/sh\nprintf "%s\0" "$@" >"$CALLS"\n' > "$fakebin/curl"
chmod +x "$fakebin/curl"

Точный код и сообщение связывают тест с нужной ветвью; дополнительно проверяют, что внешняя команда не была вызвана. Заглушка записывает аргументы с NUL-разделителем, позволяя проверить границы; переменная CALLS должна быть экспортирована и путь защищён. Фиксация окружения делает сортировку, даты и права воспроизводимее; umask — команда оболочки и не задаётся как простая переменная перед процессом. Алиасы обычно не наследуются неинтерактивным дочерним Bash и не подменяют команду в отдельном сценарии. Тест проверяет отказ и то, что незавершённый артефакт не остался как активный результат.

Вопрос 4 из 30

В служебном сценарии найден следующий фрагмент по теме «Проверка ошибок». Не предполагая намерение автора, что можно утверждать об этой конструкции?

run env FAIL_STEP=copy ./deploy.sh
[ "$status" -ne 0 ]
[ ! -e "$TARGET/current.new" ]

Любая ошибка удовлетворяет проверке: сценарий может упасть по другой причине до валидации аргумента. Тест проверяет отказ и то, что незавершённый артефакт не остался как активный результат. Фиксация окружения делает сортировку, даты и права воспроизводимее; umask — команда оболочки и не задаётся как простая переменная перед процессом. ShellCheck предупредит о разбиении вывода find, потому что имена с пробелами и переводами строк повредятся. Новая версия образа может добавить предупреждение и внезапно сломать сборку; результат трудно воспроизвести спустя время.

Вопрос 5 из 30

В служебном сценарии найден следующий фрагмент по теме «Проверка и диагностика». Какое утверждение точно относится к показанному фрагменту?

LC_ALL=C TZ=UTC umask 077
./script.sh

Новая версия образа может добавить предупреждение и внезапно сломать сборку; результат трудно воспроизвести спустя время. Локаль и часовой пояс передаются процессу, а umask нужно установить в родительской оболочке или обёртке. Любая ошибка удовлетворяет проверке: сценарий может упасть по другой причине до валидации аргумента. Порог только error пропускает многие важные предупреждения о кавычках и переносимости; политику уровней нужно выбирать по риску, а не ради зелёной сборки. Фиксация окружения делает сортировку, даты и права воспроизводимее; umask — команда оболочки и не задаётся как простая переменная перед процессом.

Вопрос 6 из 30

В служебном сценарии найден следующий фрагмент по теме «Безопасность и переносимость». Какой вывод об этом варианте можно сделать без догадок о внешнем контексте?

docker run --rm koalaman/shellcheck:latest script.sh

Новая версия образа может добавить предупреждение и внезапно сломать сборку; результат трудно воспроизвести спустя время. Заглушка записывает аргументы с NUL-разделителем, позволяя проверить границы; переменная CALLS должна быть экспортирована и путь защищён. Локальный PATH направляет поиск curl к заглушке только для тестируемого процесса, не меняя глобальную систему. Любая ошибка удовлетворяет проверке: сценарий может упасть по другой причине до валидации аргумента. Фиксированная версия делает аудит воспроизводимым, а обновление выполняется отдельным осознанным изменением.

Вопрос 7 из 30

При проверке темы «Статический анализ» в тесте «ShellCheck и тестирование скриптов» нужно оценить именно этот вариант. Какой вывод наиболее точно привязан к показанной реализации?

# shellcheck disable=SC2044
for f in $(find . -type f); do ...; done

Локальный PATH направляет поиск curl к заглушке только для тестируемого процесса, не меняя глобальную систему. Переписывание устраняет первопричину и сохраняет произвольные имена; ShellCheck затем проверяет соседние ошибки. Заглушка записывает аргументы с NUL-разделителем, позволяя проверить границы; переменная CALLS должна быть экспортирована и путь защищён. Общий путь /tmp/result создаёт конфликты между параллельными тестами и может использовать старый файл от предыдущего запуска. Подавление предупреждения не исправляет дефект и превращает осознанный риск в постоянную слепую зону.

Вопрос 8 из 30

При проверке темы «Тестирование через Bats» в тесте «ShellCheck и тестирование скриптов» нужно оценить именно этот вариант. Какое утверждение о поведении кода остаётся точным на граничном входе?

@test "creates file" { ./script.sh; [ -f /tmp/result ]; }

Общий путь /tmp/result создаёт конфликты между параллельными тестами и может использовать старый файл от предыдущего запуска. ShellCheck предупредит о разбиении вывода find, потому что имена с пробелами и переводами строк повредятся. Алиасы обычно не наследуются неинтерактивным дочерним Bash и не подменяют команду в отдельном сценарии. Отдельный временный каталог изолирует тест, но путь нужно передавать сценарию через явную настройку. Точный код и сообщение связывают тест с нужной ветвью; дополнительно проверяют, что внешняя команда не была вызвана.

Вопрос 9 из 30

При проверке темы «Тестовые окружения» в тесте «ShellCheck и тестирование скриптов» нужно оценить именно этот вариант. Что важно заметить в этом фрагменте до его включения в автоматизацию?

alias curl='echo fake'
./script.sh

Любая ошибка удовлетворяет проверке: сценарий может упасть по другой причине до валидации аргумента. Алиасы обычно не наследуются неинтерактивным дочерним Bash и не подменяют команду в отдельном сценарии. Подстановка команд удаляет хвостовые переводы строк и может скрыть различие; для байтового сравнения лучше cmp с файлами. Фиксация окружения делает сортировку, даты и права воспроизводимее; umask — команда оболочки и не задаётся как простая переменная перед процессом. Локальный PATH направляет поиск curl к заглушке только для тестируемого процесса, не меняя глобальную систему.

Вопрос 10 из 30

При проверке темы «Проверка ошибок» в тесте «ShellCheck и тестирование скриптов» нужно оценить именно этот вариант. Что действительно гарантирует или, наоборот, не гарантирует эта конструкция?

run ./script.sh bad
[ "$status" -ne 0 ]

Фиксированная версия делает аудит воспроизводимым, а обновление выполняется отдельным осознанным изменением. Любая ошибка удовлетворяет проверке: сценарий может упасть по другой причине до валидации аргумента. Порог только error пропускает многие важные предупреждения о кавычках и переносимости; политику уровней нужно выбирать по риску, а не ради зелёной сборки. Точный код и сообщение связывают тест с нужной ветвью; дополнительно проверяют, что внешняя команда не была вызвана. Тест запускает сценарий без аргументов и проверяет именно код ошибки использования 64.

Вопрос 11 из 30

При проверке темы «Проверка и диагностика» в тесте «ShellCheck и тестирование скриптов» нужно оценить именно этот вариант. Фрагмент запускают как часть служебного сценария. Как его следует оценить?

env LC_ALL=C TZ=UTC ./script.sh

Алиасы обычно не наследуются неинтерактивным дочерним Bash и не подменяют команду в отдельном сценарии. Заглушка записывает аргументы с NUL-разделителем, позволяя проверить границы; переменная CALLS должна быть экспортирована и путь защищён. Подстановка команд удаляет хвостовые переводы строк и может скрыть различие; для байтового сравнения лучше cmp с файлами. Тест запускает сценарий без аргументов и проверяет именно код ошибки использования 64. Локаль и часовой пояс передаются процессу, а umask нужно установить в родительской оболочке или обёртке.

Вопрос 12 из 30

При проверке темы «Безопасность и переносимость» в тесте «ShellCheck и тестирование скриптов» нужно оценить именно этот вариант. Какой вывод наиболее точно привязан к показанной реализации?

docker run --rm koalaman/shellcheck:v0.10.0 script.sh

Фиксированная версия делает аудит воспроизводимым, а обновление выполняется отдельным осознанным изменением. Тест запускает сценарий без аргументов и проверяет именно код ошибки использования 64. Отдельный временный каталог изолирует тест, но путь нужно передавать сценарию через явную настройку. Алиасы обычно не наследуются неинтерактивным дочерним Bash и не подменяют команду в отдельном сценарии. Порог только error пропускает многие важные предупреждения о кавычках и переносимости; политику уровней нужно выбирать по риску, а не ради зелёной сборки.

Вопрос 13 из 30

В тесте «ShellCheck и тестирование скриптов» показан фрагмент из блока «Статический анализ». Какое суждение правильно описывает показанную реализацию?

while IFS= read -r -d '' f; do ...; done < <(find . -type f -print0)

Алиасы обычно не наследуются неинтерактивным дочерним Bash и не подменяют команду в отдельном сценарии. Переписывание устраняет первопричину и сохраняет произвольные имена; ShellCheck затем проверяет соседние ошибки. Точный код и сообщение связывают тест с нужной ветвью; дополнительно проверяют, что внешняя команда не была вызвана. Любая ошибка удовлетворяет проверке: сценарий может упасть по другой причине до валидации аргумента. ShellCheck предупредит о разбиении вывода find, потому что имена с пробелами и переводами строк повредятся.

Вопрос 14 из 30

В тесте «ShellCheck и тестирование скриптов» показан фрагмент из блока «Тестирование через Bats». Какой ответ учитывает и полезный эффект, и остающееся ограничение кода?

setup() { TEST_TMP=$(mktemp -d); }
teardown() { rm -rf -- "$TEST_TMP"; }

Фиксация окружения делает сортировку, даты и права воспроизводимее; umask — команда оболочки и не задаётся как простая переменная перед процессом. Любая ошибка удовлетворяет проверке: сценарий может упасть по другой причине до валидации аргумента. Отдельный временный каталог изолирует тест, но путь нужно передавать сценарию через явную настройку. ShellCheck предупредит о разбиении вывода find, потому что имена с пробелами и переводами строк повредятся. Тест запускает сценарий без аргументов и проверяет именно код ошибки использования 64.

Вопрос 15 из 30

В тесте «ShellCheck и тестирование скриптов» показан фрагмент из блока «Тестовые окружения». Код предлагают как альтернативу. Какова его точная техническая оценка?

PATH="$fakebin:/usr/bin:/bin" CALLS="$calls" ./script.sh

Локальный PATH направляет поиск curl к заглушке только для тестируемого процесса, не меняя глобальную систему. Подавление предупреждения не исправляет дефект и превращает осознанный риск в постоянную слепую зону. Переписывание устраняет первопричину и сохраняет произвольные имена; ShellCheck затем проверяет соседние ошибки. Локаль и часовой пояс передаются процессу, а umask нужно установить в родительской оболочке или обёртке. Заглушка записывает аргументы с NUL-разделителем, позволяя проверить границы; переменная CALLS должна быть экспортирована и путь защищён.

Вопрос 16 из 30

В тесте «ShellCheck и тестирование скриптов» показан фрагмент из блока «Проверка ошибок». Что является главным свойством этого варианта?

[ "$status" -eq 64 ]
[[ $output == *"invalid mode"* ]]

Фиксированная версия делает аудит воспроизводимым, а обновление выполняется отдельным осознанным изменением. Общий путь /tmp/result создаёт конфликты между параллельными тестами и может использовать старый файл от предыдущего запуска. Точный код и сообщение связывают тест с нужной ветвью; дополнительно проверяют, что внешняя команда не была вызвана. Тест проверяет отказ и то, что незавершённый артефакт не остался как активный результат. Порог только error пропускает многие важные предупреждения о кавычках и переносимости; политику уровней нужно выбирать по риску, а не ради зелёной сборки.

Вопрос 17 из 30

В тесте «ShellCheck и тестирование скриптов» показан фрагмент из блока «Проверка и диагностика». Как следует оценить конструкцию, не считая её автоматически исправлением?

expected=$(printf 'a\nb')
[ "$output" = "$expected" ]

Подстановка команд удаляет хвостовые переводы строк и может скрыть различие; для байтового сравнения лучше cmp с файлами. Тест запускает сценарий без аргументов и проверяет именно код ошибки использования 64. Локальный PATH направляет поиск curl к заглушке только для тестируемого процесса, не меняя глобальную систему. Фиксация окружения делает сортировку, даты и права воспроизводимее; umask — команда оболочки и не задаётся как простая переменная перед процессом. Отдельный временный каталог изолирует тест, но путь нужно передавать сценарию через явную настройку.

Вопрос 18 из 30

В тесте «ShellCheck и тестирование скриптов» показан фрагмент из блока «Безопасность и переносимость». Какое суждение правильно описывает показанную реализацию?

shellcheck -S error script.sh

Фиксация окружения делает сортировку, даты и права воспроизводимее; umask — команда оболочки и не задаётся как простая переменная перед процессом. Отдельный временный каталог изолирует тест, но путь нужно передавать сценарию через явную настройку. Порог только error пропускает многие важные предупреждения о кавычках и переносимости; политику уровней нужно выбирать по риску, а не ради зелёной сборки. Новая версия образа может добавить предупреждение и внезапно сломать сборку; результат трудно воспроизвести спустя время. Подавление предупреждения не исправляет дефект и превращает осознанный риск в постоянную слепую зону.

Вопрос 19 из 30

На техническом ревью обсуждают раздел «Статический анализ». На какой границе эта техника перестаёт быть достаточной сама по себе?

Тест ошибок должен контролировать восстановление прав, временных файлов и блокировок; отсутствие конечного файла не означает чистый откат. Заглушка должна моделировать коды, задержки, stderr и частичный вывод; всегда успешный fake проверяет лишь счастливую ветвь. Проверка только output объединяет stdout и иногда форматирование Bats; для протокола полезно тестировать отдельные файлы потоков и точные байты. ShellCheck предупредит о разбиении вывода find, потому что имена с пробелами и переводами строк повредятся. Директивы source и disable должны иметь узкую область и комментарий причины; глобальное исключение номера правила ухудшает будущий аудит.

Вопрос 20 из 30

На техническом ревью обсуждают раздел «Тестирование через Bats». Где заканчивается защита, которую даёт рассматриваемая конструкция?

Проверка только output объединяет stderr и иногда форматирование Bats; для протокола полезно тестировать отдельные файлы потоков и точные байты. Заглушка должна моделировать коды, задержки, stderr и частичный вывод; всегда успешный fake проверяет лишь счастливую ветвь. Тест ошибок должен контролировать восстановление прав, временных файлов и блокировок; отсутствие конечного файла не означает чистый откат. Директивы source и disable должны иметь узкую область и комментарий причины; глобальное исключение номера правила ухудшает будущий аудит. Проверка только output объединяет stdout и иногда форматирование Bats; для протокола полезно тестировать отдельные файлы потоков и точные байты.

Вопрос 21 из 30

На техническом ревью обсуждают раздел «Тестовые окружения». Что способно нарушить ожидаемый результат, хотя основной фрагмент написан корректно?

Заглушка должна моделировать коды, задержки, stderr и частичный вывод; всегда успешный fake проверяет лишь счастливую ветвь. При падении тест должен сохранять временный каталог и трассу только по запросу, иначе диагностика теряется или, наоборот, засоряет систему секретами. Тест ошибок должен контролировать восстановление прав, временных файлов и блокировок; отсутствие конечного файла не означает чистый откат. Заглушка должна моделировать коды, задержки, stderr и частичный вывод; всегда успешный fake не проверяет лишь счастливую ветвь. Проверка только output объединяет stdout и иногда форматирование Bats; для протокола полезно тестировать отдельные файлы потоков и точные байты.

Вопрос 22 из 30

На техническом ревью обсуждают раздел «Проверка ошибок». Какой эксплуатационный компромисс здесь нельзя скрывать за успешным кодом возврата?

Заглушка должна моделировать коды, задержки, stderr и частичный вывод; всегда успешный fake проверяет лишь счастливую ветвь. Тест ошибок должен контролировать восстановление прав, временных файлов и блокировок; отсутствие конечного файла не означает чистый откат. Тестовые контейнеры могут скрыть различия реальной файловой системы, systemd и прав; часть проверок должна выполняться в среде, близкой к эксплуатации. При падении тест должен сохранять временный каталог и трассу только по запросу, иначе диагностика теряется или, наоборот, засоряет систему секретами. Тест проверяет отказ и то, что незавершённый артефакт не остался как активный результат.

Вопрос 23 из 30

На техническом ревью обсуждают раздел «Проверка и диагностика». Что обязательно нужно проверить в соседнем сценарии, чтобы не получить ложную надёжность?

При падении тест должен сохранять временный каталог и трассу только по запросу, иначе диагностика теряется или, наоборот, засоряет систему секретами. Фиксация окружения делает сортировку, даты и права воспроизводимее; umask — команда оболочки и не задаётся как простая переменная перед процессом. Тест ошибок должен контролировать восстановление прав, временных файлов и блокировок; отсутствие конечного файла не означает чистый откат. Заглушка должна моделировать коды, задержки, stderr и частичный вывод; всегда успешный fake проверяет лишь счастливую ветвь. Тестовые контейнеры могут скрыть различия реальной файловой системы, systemd и прав; часть проверок должна выполняться в среде, близкой к эксплуатации.

Вопрос 24 из 30

На техническом ревью обсуждают раздел «Безопасность и переносимость». На какой границе эта техника перестаёт быть достаточной сама по себе?

Тестовые контейнеры могут скрыть различия реальной файловой системы, systemd и прав; часть проверок должна выполняться в среде, близкой к эксплуатации. Новая версия образа может добавить предупреждение и внезапно сломать сборку; результат трудно воспроизвести спустя время. Тест ошибок должен контролировать восстановление прав, временных файлов и блокировок; отсутствие конечного файла не означает чистый откат. При падении тест должен сохранять временный каталог и трассу только по запросу, иначе диагностика теряется или, наоборот, засоряет систему секретами. Заглушка должна моделировать коды, задержки, stderr и частичный вывод; всегда успешный fake проверяет лишь счастливую ветвь.

Вопрос 25 из 30

Для темы «Статический анализ» нужно отделить свойство механизма от удачного примера. Какое утверждение точнее всего описывает контракт рассматриваемого механизма?

ShellCheck обнаруживает распространённые ошибки разбиения, glob, статусов и переносимости, но не знает бизнес-контракт и фактические данные. CI должен запускать ShellCheck с выбранной версией и тесты под поддерживаемыми оболочками; плавающий latest меняет правила без изменения проекта. Bats запускает каждый тест в отдельном процессе Bash и предоставляет status, output и массив lines после run; изменения окружения не всегда переходят между тестами. ShellCheck предупредит о разбиении вывода find, потому что имена с пробелами и переводами строк повредятся. Надёжный тест подменяет внешние команды через временный PATH с контролируемыми заглушками и фиксирует все аргументы без eval.

Вопрос 26 из 30

Для темы «Тестирование через Bats» нужно отделить свойство механизма от удачного примера. Какое правило позволяет правильно разобрать эту тему до запуска кода?

Команда run выполняет программу в текущем процессе теста, поэтому присваивания и смена каталога внутри проверяемого сценария остаются видимыми после run. Переменная lines является одной строкой с переводами строк; обращение lines[1] выполняет обычное разбиение по пробелам. После run переменная status содержит стандартный вывод команды, а output — её числовой код завершения. Все тесты одного файла Bats выполняются в общей оболочке, поэтому изменения переменных и функций из предыдущего теста гарантированно сохраняются. Bats запускает каждый тест в отдельном процессе Bash и предоставляет status, output и массив lines после run; изменения окружения не всегда переходят между тестами.

Вопрос 27 из 30

Для темы «Тестовые окружения» нужно отделить свойство механизма от удачного примера. Какое свойство механизма нельзя подменять удачным примером запуска?

Bats запускает каждый тест в отдельном процессе Bash и предоставляет status, output и массив lines после run; изменения окружения не всегда переходят между тестами. Надёжный тест подменяет внешние команды через временный PWD с контролируемыми заглушками и фиксирует все аргументы без eval. Негативный тест должен подтвердить не только ненулевой код, но и отсутствие запрещённого побочного эффекта после частичного сбоя. CI должен запускать ShellCheck с выбранной версией и тесты под поддерживаемыми оболочками; плавающий latest меняет правила без изменения проекта. Надёжный тест подменяет внешние команды через временный PATH с контролируемыми заглушками и фиксирует все аргументы без eval.

Вопрос 28 из 30

Для темы «Проверка ошибок» нужно отделить свойство механизма от удачного примера. Какая формулировка связывает частные примеры одним проверяемым правилом?

Bats запускает каждый тест в отдельном процессе Bash и предоставляет status, output и массив lines после run; изменения окружения не всегда переходят между тестами. Тест проверяет отказ и то, что незавершённый артефакт не остался как активный результат. Негативный тест должен подтвердить не только ненулевой код, но и отсутствие запрещённого побочного эффекта после частичного сбоя. Надёжный тест подменяет внешние команды через временный PATH с контролируемыми заглушками и фиксирует все аргументы без eval. Тесты shell-кода нестабильны, если зависят от текущей локали, времени, umask, порядка файлов и установленного набора утилит.

Вопрос 29 из 30

Для темы «Проверка и диагностика» нужно отделить свойство механизма от удачного примера. Что в этой теме является свойством языка, а не случайностью конкретного запуска?

Надёжный тест подменяет внешние команды через временный PATH с контролируемыми заглушками и фиксирует все аргументы без eval. Фиксация окружения делает сортировку, даты и права воспроизводимее; umask — команда оболочки и не задаётся как простая переменная перед процессом. CI должен запускать ShellCheck с выбранной версией и тесты под поддерживаемыми оболочками; плавающий latest меняет правила без изменения проекта. Негативный тест должен подтвердить не только ненулевой код, но и отсутствие запрещённого побочного эффекта после частичного сбоя. Тесты shell-кода нестабильны, если зависят от текущей локали, времени, umask, порядка файлов и установленного набора утилит.

Вопрос 30 из 30

Для темы «Безопасность и переносимость» нужно отделить свойство механизма от удачного примера. Какое утверждение точнее всего описывает контракт рассматриваемого механизма?

ShellCheck обнаруживает распространённые ошибки разбиения, glob, статусов и переносимости, но не знает бизнес-контракт и фактические данные. Надёжный тест подменяет внешние команды через временный PATH с контролируемыми заглушками и фиксирует все аргументы без eval. CI должен запускать ShellCheck с выбранной версией и тесты под поддерживаемыми оболочками; плавающий latest не меняет правила без изменения проекта. CI должен запускать ShellCheck с выбранной версией и тесты под поддерживаемыми оболочками; плавающий latest меняет правила без изменения проекта. Тесты shell-кода нестабильны, если зависят от текущей локали, времени, umask, порядка файлов и установленного набора утилит.