DevOps 지식 허브
DevOps 지식 허브

Bash 스크립트를 효과적으로 테스트하는 방법

자동화를 확인하기 위해 수동 실행에 의존하는 것을 멈추십시오. 이 가이드는 Bash 스크립트를 효과적으로 테스트하기 위한 전문가 전략을 제공합니다. `set -e` 및 `set -u`를 사용하여 필수적인 방어적 코딩 기술을 배우고, Bats(Bash 자동화 테스트 시스템) 및 ShUnit2와 같은 강력하고 실용적인 프레임워크를 발견하십시오. 우리는 신뢰할 수 있는 단위 및 통합 테스트를 위해 종속성을 격리하고, 입력/출력 어설션을 관리하며, 임시 환경을 사용하는 모범 사례를 다루어 스크립트가 강력하고 이식성이 있도록 보장합니다.

31 조회수

Bash 스크립트를 효과적으로 테스트하는 방법

Bash 스크립트는 수많은 자동화, 배포 및 시스템 유지 관리 작업의 중추입니다. 단순한 스크립트는 명확해 보일 수 있지만, 정확성을 확인하기 위해 수동 실행에만 의존하는 것은 프로덕션 실패로 이어지는 빠른 길입니다. 효과적인 테스트는 자동화가 견고하고, 엣지 케이스를 원활하게 처리하며, 다양한 환경에서 신뢰성을 유지하도록 보장하는 데 매우 중요합니다.

이 기사는 Bash 스크립트 테스트 전략을 구현하기 위한 포괄적인 가이드를 제공합니다. 우리는 기본적인 방어적 코딩 관행을 다루고, Bats 및 ShUnit2와 같은 인기 있는 단위 테스트 프레임워크를 살펴보고, 테스트를 개발 워크플로에 통합하기 위한 모범 사례를 논의할 것입니다.

기본 사항: 방어적 코딩 및 디버깅

공식적인 단위 테스트를 구현하기 전에, 버그에 대한 첫 번째 방어 계층은 스크립트 자체의 구조에 있습니다. 엄격한 운영 설정을 활용하면 미묘한 런타임 오류를 즉각적인 실패로 전환하여 디버깅을 더 쉽게 할 수 있습니다.

필수 방어 헤더

모든 견고한 Bash 스크립트는 종종 "견고한 헤더"라고 불리는 다음 표준 옵션 세트로 시작해야 합니다:

#!/bin/bash
# 명령이 0이 아닌 상태로 종료되면 즉시 종료합니다.
set -e

# 설정되지 않은 변수를 대체할 때 오류로 처리합니다.
set -u

# 파이프라인의 오류가 가려지는 것을 방지합니다.
set -o pipefail

팁: 이러한 옵션을 set -euo pipefail로 결합하는 것은 전문 스크립트의 표준 관행입니다.

추적을 사용한 수동 디버깅

빠른 디버깅이나 스크립트 실행 흐름을 이해하기 위해 Bash는 내장된 추적 기능을 제공합니다:

  • 명령 추적 (-x): 실행되는 명령과 그 인수를 + 접두사와 함께 출력합니다.
  • 실행 안 함 (-n): 명령을 읽지만 실행하지 않습니다 (구문 오류 확인에 유용).

스크립트를 실행할 때 또는 스크립트 내부에서 추적을 활성화할 수 있습니다:

# 추적을 사용하여 스크립트 실행
bash -x ./my_script.sh

# 특정 섹션 내에서 추적 활성화
echo "Starting complex operation..."
set -x # 추적 활성화
complex_function_call arg1 arg2
set +x # 추적 비활성화
echo "Operation finished."

공식 단위 테스트 프레임워크 도입

수동 디버깅은 복잡한 로직에 대해 지속 불가능합니다. 공식 단위 테스트 프레임워크를 사용하면 반복 가능한 테스트 케이스를 정의하고, 예상되는 결과를 단언하며, 검증 프로세스를 자동화할 수 있습니다.

1. Bats (Bash Automated Testing System)

Bats는 Bash 테스트를 위한 가장 인기 있고 쉬운 프레임워크라고 할 수 있습니다. 친숙한 Bash 구문을 사용하여 테스트를 작성할 수 있어, 단언(assertion)을 간단하고 읽기 쉽게 만듭니다.

Bats의 주요 특징:

  • 테스트는 표준 Bash 함수로 작성됩니다.
  • 대상 스크립트/함수를 실행하기 위해 간단한 run 명령을 사용합니다.
  • $status, $output, $lines와 같은 내장 단언 변수를 제공합니다.

예시: 간단한 함수 테스트

함수 calculate_sum을 포함하는 스크립트(calculator.sh)가 있다고 가정해 보겠습니다.

calculator.sh 스니펫:

calculate_sum() {
  if [[ $# -ne 2 ]]; then
    echo "Error: Requires two arguments" >&2
    return 1
  fi
  echo $(( $1 + $2 ))
}

test/calculator.bats:

#!/usr/bin/env bats

# 테스트할 함수가 포함된 스크립트 소싱
load '../calculator.sh'

@test "Valid inputs should return the correct sum" {
  run calculate_sum 10 5
  # 함수가 성공 상태 (0)를 반환했는지 단언합니다.
  [ "$status" -eq 0 ]
  # 출력이 예상과 일치하는지 단언합니다.
  [ "$output" -eq 15 ]
}

@test "Missing inputs should return error status (1)" {
  run calculate_sum 5
  [ "$status" -ne 0 ]
  [ "$status" -eq 1 ]
  # 표준 에러 내용 확인 (에러 메시지가 stderr로 출력된 경우)
  # [ "$stderr" = "Error: Requires two arguments" ] 
}

테스트를 실행하려면:

$ bats test/calculator.bats

2. ShUnit2

ShUnit2는 xUnit 스타일의 테스트를 따르므로 Python 또는 Java와 같은 언어에서 온 개발자들에게 친숙합니다. 프레임워크 파일 소싱이 필요하며 엄격한 명명 규칙(setUp, tearDown, test_...)을 준수합니다.

ShUnit2의 주요 특징:

  • 정리를 위한 설정(setup) 및 해체(teardown) 루틴을 지원합니다.
  • 풍부한 내장 단언 함수(예: assertTrue, assertEquals)를 제공합니다.

ShUnit2 구조

#!/bin/bash
# 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. 입력, 출력 및 오류 처리

테스트는 Bash에서 성공 또는 실패를 알리는 주요 메커니즘인 표준 스트림(stdout, stderr)과 최종 종료 코드(exit code)를 확인해야 합니다.

  • 종료 코드(Exit Codes): 성공을 위해서는 항상 status -eq 0을, 특정 오류 조건(예: 구문 분석 실패, 파일을 찾을 수 없음)에 대해서는 0이 아닌 값을 테스트해야 합니다.
  • 표준 출력 (stdout): 이는 일반적으로 기본 데이터 출력입니다. 정확성을 단언하기 위해 Bats의 $output을 사용하거나 ShUnit2에서 출력을 캡처하십시오.
  • 표준 오류 (stderr): 오류, 경고 및 디버깅 메시지는 이쪽으로 라우팅되어야 합니다. 결정적으로, 프로덕션 스크립트는 성공적으로 실행되는 동안 stderr에 조용해야 합니다.

2. 종속성 격리 (Mocking)

단위 테스트는 외부 시스템 도구(예: curl, kubectl, git)가 아닌 당신의 코드를 테스트해야 합니다. 스크립트가 외부 명령에 의존하는 경우, 테스트 중에 해당 명령을 모의(mock)해야 합니다.

방법: 실제 종속성과 동일한 이름을 가진 모의 실행 파일이 포함된 임시 디렉터리를 만듭니다. 테스트를 실행하기 전에 이 디렉터리를 $PATH에 추가하여, 스크립트가 실제 도구 대신 모의를 호출하도록 보장합니다.

모의 예시:

#!/bin/bash
# 파일: /tmp/mock_bin/curl

if [[ "$1" == "--version" ]]; then
  echo "Mock Curl 7.6"
  exit 0
else
  # 성공적인 다운로드 응답 시뮬레이션
  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 -
  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(지속적 통합/지속적 배포) 파이프라인에 통합하십시오.

  1. 버전 관리: 테스트 디렉터리(예: test/)를 소스 스크립트와 함께 저장하십시오.
  2. Pre-Commit Hooks: 커밋 전에 shellcheck(정적 분석 도구)와 포맷터 같은 도구를 사용하여 코드 품질을 보장하십시오.
  3. CI 자동화: CI 서버(GitHub Actions, GitLab CI, Jenkins)를 구성하여 푸시할 때마다 Bats 또는 ShUnit2 테스트 스위트를 자동으로 실행하도록 하십시오. 테스트가 0이 아닌 상태를 반환하면 빌드를 실패 처리하십시오.

경고: shellcheck와 같은 정적 분석 도구는 단위 테스트의 훌륭한 동반자입니다. 이들은 테스트가 놓칠 수 있는 일반적인 실수, 이식성 문제 및 보안 취약성을 포착합니다. 사전 테스트 루틴의 일부로 항상 shellcheck를 실행하십시오.

결론

Bash 스크립트 테스트는 신뢰할 수 없는 자동화를 신뢰할 수 있는 인프라 코드로 전환합니다. 방어적 코딩(set -euo pipefail)을 채택하고, 간소화된 단위 테스트를 위해 Bats와 같은 전문 프레임워크를 활용하며, 세심한 종속성 격리를 실천함으로써 런타임 오류의 위험을 크게 줄일 수 있습니다. 강력한 테스트 스위트를 구축하는 데 시간을 투자하는 것은 미션 크리티컬 자동화의 안정성, 유지 관리성 및 신뢰도에서 큰 이점을 가져옵니다.