0Pricing
DevOps Bootcamp · 강의

테스트 픽스처, 임시 환경 및 커버리지

격리된 테스트 픽스처를 만들고 테스트가 실제로 실행하는 스크립트 분기를 측정합니다.

테스트 픽스처, 임시 환경 및 커버리지은(는) CoddyKit의 무료 DevOps Bootcamp 강의입니다. 이것은 4개 중 3번째 강의입니다. 아래에서 전체 강의를 무료로 읽을 수 있으며, 내장 코드 에디터와 24/7 AI 튜터와 함께 브라우저에서 직접 실습할 수 있습니다. 이 강의는 DevOps Bootcamp 학습 경로의 일부이며, 진행 상황이 웹과 CoddyKit 앱에 동기화됩니다. DevOps Bootcamp 강의에는 총 4개의 강의가 포함되어 있습니다.

테스트 픽스처와 격리가 중요한 이유

Bash 스크립트를 테스트할 때 가장 큰 위험은 부수 효과입니다. 테스트가 실수로 실제 파일, 실제 데이터베이스 또는 실제 시스템 상태를 변경할 수 있기 때문입니다. 내 컴퓨터에서는 통과하지만 운영 데이터를 손상시키는 테스트는 테스트가 전혀 없는 것보다 나쁩니다.

해결책은 실제 환경을 모방하면서도 실제 대상에는 손대지 않는, 통제되고 폐기 가능한 환경인 테스트 픽스처입니다. 좋은 픽스처는 다음을 제공합니다.

  • 재현성 — 테스트가 실행될 때마다 같은 결과를 냅니다.
  • 격리 — 테스트끼리 또는 호스트와 서로 간섭하지 않습니다.
  • 안전성 — 파괴적인 작업이 버려도 되는 데이터에만 영향을 줍니다.
  • 속도 — 꼭 필요한 경우가 아니면 네트워크 호출이나 무거운 입출력을 수행하지 않습니다.

Bash 테스트에서 픽스처는 일반적으로 알려진 파일을 채운 임시 디렉터리, $PATH 앞부분에 배치한 모의 실행 파일, 그리고 테스트 프로세스에 한정된 환경 변수로 구성됩니다.

임시 디렉터리 만들기와 정리하기

테스트별 임시 디렉터리를 만드는 표준 패턴은 mktemp -d를 사용하는 것입니다. 이 명령은 /tmp에 고유한 디렉터리를 만들고 그 경로를 출력합니다. 경로를 저장한 다음 trap을 등록하여 셸이 종료될 때, 실패한 경우에도 자동으로 디렉터리를 삭제하게 합니다.

파일 시스템을 사용하는 모든 테스트 파일에는 다음 두 줄 관용구가 있어야 합니다.

#!/usr/bin/env bash
set -euo pipefail

# Create an isolated temp directory
TMPDIR=$(mktemp -d)
# Always clean up, even if the script exits early or errors out
trap 'rm -rf "$TMPDIR"' EXIT

echo "Working in: $TMPDIR"

# Simulate creating fixture files
mkdir -p "$TMPDIR/project/{src,tests,logs}"
echo 'version=1.2.3' > "$TMPDIR/project/.env"
echo 'Hello fixture' > "$TMPDIR/project/src/main.sh"

ls -R "$TMPDIR/project"
echo 'Temp dir will be removed automatically on exit'

픽스처 디렉터리 트리 구성하기

잘 구성된 픽스처는 테스트 대상 스크립트가 실제로 기대하는 디렉터리 배치를 그대로 반영합니다. 이를 작은 가짜 프로젝트 루트라고 생각하면 됩니다. 픽스처 설정 함수는 각 테스트 전에 이 배치를 만들고, 정리 함수는 이를 삭제합니다.

핵심 실천 방법:

  • 테스트 프레임워크가 각 테스트 전에 호출하는 setup() 함수를 사용하십시오.
  • 실패한 경우에도 각 테스트 후에 실행되는 teardown() 또는 cleanup()을 사용하십시오.
  • 픽스처 파일은 최소한으로 유지하고, 스크립트가 실제로 읽는 것만 포함하십시오.
  • 실패 원인을 쉽게 파악할 수 있도록 픽스처 파일의 이름을 설명적으로 지정하십시오.
#!/usr/bin/env bash
# fixture_helpers.bash — source this from your test files

FIXTURE_ROOT=''

setup_fixture() {
  FIXTURE_ROOT=$(mktemp -d)
  # Build the directory tree the deploy script expects
  mkdir -p "$FIXTURE_ROOT"/{dist,config,logs}
  echo '{"version":"2.0"}' > "$FIXTURE_ROOT/config/app.json"
  echo 'console.log("app")' > "$FIXTURE_ROOT/dist/index.js"
  touch "$FIXTURE_ROOT/logs/.gitkeep"
  export FIXTURE_ROOT
  echo "[setup] Fixture ready at $FIXTURE_ROOT"
}

teardown_fixture() {
  if [[ -n "$FIXTURE_ROOT" && -d "$FIXTURE_ROOT" ]]; then
    rm -rf "$FIXTURE_ROOT"
    echo '[teardown] Fixture removed'
  fi
}

# Self-test
setup_fixture
ls "$FIXTURE_ROOT"
teardown_fixture

가짜 PATH로 실행 파일 모킹하기

많은 Bash 스크립트가 curl, aws, docker, git 같은 외부 도구를 호출합니다. 테스트에서는 실제 서비스에 접속하고 싶지 않으므로 이러한 도구를 가짜 실행 파일로 대체합니다.

방법은 간단합니다.

  1. 픽스처 안에 임시 bin/ 디렉터리를 만듭니다.
  2. 실제 도구와 같은 이름의 작은 셸 스크립트를 그곳에 작성합니다.
  3. 테스트 대상 스크립트를 호출하기 전에 해당 디렉터리를 $PATH 앞에 추가합니다.

$PATH는 왼쪽에서 오른쪽 순서로 검색되므로 가짜 실행 파일이 선택됩니다. 실제 바이너리는 호출되지 않습니다.

#!/usr/bin/env bash
set -euo pipefail

FIXTURE=$(mktemp -d)
trap 'rm -rf "$FIXTURE"' EXIT

# Create a fake 'curl' that records calls and returns canned data
FAKE_BIN="$FIXTURE/bin"
mkdir -p "$FAKE_BIN"

cat > "$FAKE_BIN/curl" << 'SCRIPT'
#!/usr/bin/env bash
# Log every argument for later inspection
echo "curl $*" >> "$FIXTURE_BIN_LOG"
# Return a canned HTTP 200 response body
echo '{"status":"ok","id":42}'
SCRIPT
chmod +x "$FAKE_BIN/curl"

# Export the log path so the fake can find it
export FIXTURE_BIN_LOG="$FIXTURE/curl_calls.log"

# Prepend fake bin directory to PATH
export PATH="$FAKE_BIN:$PATH"

# Now any call to 'curl' hits our fake
curl -s https://api.example.com/health
curl -X POST https://api.example.com/deploy

echo '--- Recorded curl calls ---'
cat "$FIXTURE_BIN_LOG"

명령 출력 캡처 및 검증하기

스크립트가 수행한 작업을 검증할 수 있어야 픽스처가 유용합니다. 표준 패턴은 다음과 같습니다.

  • $() 또는 프로세스 치환을 사용하여 표준 출력과 표준 오류를 변수에 캡처합니다.
  • 가짜 바이너리가 작성한 로그 파일을 확인합니다.
  • $? 또는 조건문을 사용하여 종료 코드를 명시적으로 확인합니다.
  • 특정 파일이 생성되었는지, 수정되었는지 또는 변경되지 않은 채 남았는지 확인합니다.

작고 목적이 분명한 검증 도우미를 작성하면 테스트를 읽기 쉬워지고, 문제가 발생했을 때 정확한 실패 메시지를 확인할 수 있습니다.

#!/usr/bin/env bash
set -euo pipefail

# Minimal assertion helpers
assert_eq() {
  local desc="$1" expected="$2" actual="$3"
  if [[ "$expected" == "$actual" ]]; then
    echo "PASS: $desc"
  else
    echo "FAIL: $desc"
    echo "  expected: $expected"
    echo "  actual:   $actual"
    return 1
  fi
}

assert_file_exists() {
  local desc="$1" file="$2"
  if [[ -f "$file" ]]; then
    echo "PASS: $desc"
  else
    echo "FAIL: $desc — file not found: $file"
    return 1
  fi
}

assert_contains() {
  local desc="$1" needle="$2" haystack="$3"
  if [[ "$haystack" == *"$needle"* ]]; then
    echo "PASS: $desc"
  else
    echo "FAIL: $desc — '$needle' not found in output"
    return 1
  fi
}

# Demo usage
TMPDIR=$(mktemp -d)
trap 'rm -rf "$TMPDIR"' EXIT
echo 'hello world' > "$TMPDIR/greeting.txt"
OUT=$(cat "$TMPDIR/greeting.txt")
assert_eq   'file content matches'     'hello world' "$OUT"
assert_file_exists 'greeting file created' "$TMPDIR/greeting.txt"
assert_contains    'output has hello'     'hello'       "$OUT"

테스트에서 환경 변수 범위 지정하기

스크립트는 $HOME, $CONFIG_PATH, $DATABASE_URL 같은 환경 변수에서 값을 읽는 경우가 많습니다. 테스트에서는 실제 환경을 오염시키지 않고 이러한 값을 덮어써야 합니다.

가장 안전한 방법은 명시적으로 설정한 변수만 포함하는 하위 셸에서 테스트 대상 스크립트를 실행하는 것입니다. env 명령을 사용하면 환경을 비운 다음 필요한 항목만 다시 추가할 수 있습니다.

  • env -i VAR=val ./script.sh — 완전히 깨끗한 환경
  • (export VAR=val; ./script.sh) — 부모 환경을 상속하고 지정한 값으로 덮어쓰는 하위 셸

하위 셸을 사용하면 스크립트가 $IFS, $PWD 또는 다른 전역 상태를 변경하더라도 그 변경 사항이 테스트 실행기로 되돌아가지 않습니다.

#!/usr/bin/env bash
set -euo pipefail

FIXTURE=$(mktemp -d)
trap 'rm -rf "$FIXTURE"' EXIT

# Write a tiny script under test that reads env vars
cat > "$FIXTURE/deploy.sh" << 'SCRIPT'
#!/usr/bin/env bash
set -euo pipefail
ENV_NAME=${DEPLOY_ENV:-unknown}
CFG=${CONFIG_DIR:-/etc/app}
echo "Deploying to $ENV_NAME using config from $CFG"
SCRIPT
chmod +x "$FIXTURE/deploy.sh"

echo '--- Test 1: staging env ---'
# Run in a clean subshell with explicit vars
(
  export DEPLOY_ENV=staging
  export CONFIG_DIR="$FIXTURE/config"
  "$FIXTURE/deploy.sh"
)

echo '--- Test 2: production env ---'
(
  export DEPLOY_ENV=production
  export CONFIG_DIR=/etc/prod-config
  "$FIXTURE/deploy.sh"
)

echo '--- Test 3: defaults ---'
# No env vars set — script should use its own defaults
env -i PATH="$PATH" "$FIXTURE/deploy.sh"

Bash 커버리지를 위한 kcov 소개

커버리지는 다음 질문에 답합니다. 테스트가 실제로 내 스크립트의 어느 줄(및 분기)을 실행했는가? 높은 커버리지 수치가 정확성을 보장하지는 않지만, 낮은 수치는 버그가 있을 가능성이 높은 미테스트 경로를 드러냅니다.

Bash 커버리지를 위한 주요 도구는 kcov입니다. PTRACE(Linux) 또는 dtrace(macOS)를 사용하여 OS 수준에서 스크립트를 계측하므로 소스 코드를 변경할 필요가 없습니다. 커버되지 않은 줄은 빨간색으로, 커버된 줄은 초록색으로 표시하는 HTML 보고서를 생성합니다.

기본 사용법:

  • kcov --include-path=./src coverage-out/ ./src/myscript.sh
  • 브라우저에서 coverage-out/index.html을 열어 결과를 확인합니다.
  • CI에서는 coverage-out/myscript.sh/coverage.json을 구문 분석하여 기계가 읽을 수 있는 백분율을 얻습니다.

참고: kcov는 별도로 설치해야 합니다(macOS에서는 brew install kcov, Ubuntu 20.04 이상에서는 apt install kcov).

실제 스크립트에 kcov 실행하기

배포 가능한 스크립트, 이를 실행하는 테스트, 커버리지를 측정하는 kcov 호출을 처음부터 끝까지 보여 주는 예제입니다. 나중에 여러 테스트 실행 결과를 병합할 수 있도록 출력 디렉터리를 테스트별로 지정한 점에 주목하십시오.

#!/usr/bin/env bash
# This demo shows the *structure* of a kcov workflow.
# It will not run kcov itself (not guaranteed to be installed),
# but the script under test and test runner are fully runnable.
set -euo pipefail

FIXTURE=$(mktemp -d)
trap 'rm -rf "$FIXTURE"' EXIT

# 1. Script under test
cat > "$FIXTURE/process.sh" << 'SCRIPT'
#!/usr/bin/env bash
set -euo pipefail
INPUT="$1"
if [[ ! -f "$INPUT" ]]; then
  echo "ERROR: file not found" >&2
  exit 1
fi
LINE_COUNT=$(wc -l < "$INPUT")
if (( LINE_COUNT == 0 )); then
  echo "WARNING: file is empty"
else
  echo "Processed $LINE_COUNT lines"
fi
SCRIPT
chmod +x "$FIXTURE/process.sh"

# 2. Happy path test (exercises line 6 and 11)
echo -e 'one\ntwo\nthree' > "$FIXTURE/data.txt"
OUT=$("$FIXTURE/process.sh" "$FIXTURE/data.txt")
echo "Happy path: $OUT"

# 3. Empty file test (exercises line 9)
touch "$FIXTURE/empty.txt"
OUT=$("$FIXTURE/process.sh" "$FIXTURE/empty.txt")
echo "Empty file: $OUT"

# 4. Missing file test (exercises line 5-6)
if ! OUT=$("$FIXTURE/process.sh" "$FIXTURE/missing.txt" 2>&1); then
  echo "Missing file (expected error): $OUT"
fi

# To measure coverage, wrap each call with kcov:
# kcov --include-path="$FIXTURE" "$FIXTURE/cov/happy" "$FIXTURE/process.sh" ...
# kcov --merge "$FIXTURE/cov/all" "$FIXTURE/cov/happy" "$FIXTURE/cov/empty"

여러 테스트 실행의 커버리지 병합하기

하나의 테스트만으로 모든 분기를 다루는 경우는 드뭅니다. 각 테스트를 자체 커버리지 출력 디렉터리에서 실행한 다음 병합합니다. kcov의 --merge 플래그는 여러 실행 결과를 하나의 통합 보고서로 결합합니다.

CI 파이프라인에서 일반적으로 사용하는 패턴:

  • 테스트 A 실행 → cov/test_a/에 출력
  • 테스트 B 실행 → cov/test_b/에 출력
  • 병합 → kcov --merge cov/all/ cov/test_a/ cov/test_b/
  • cov/all/<script>/coverage.json을 구문 분석하여 최종 백분율 확인

최소 임계값을 적용하여 커버리지가 그보다 낮아지면 CI 빌드가 실패하게 만들 수도 있습니다.

#!/usr/bin/env bash
# extract_coverage.sh — parse kcov JSON and fail below threshold
set -euo pipefail

MIN_COVERAGE=80   # percent
COV_JSON="${1:-coverage-out/myscript.sh/coverage.json}"

if [[ ! -f "$COV_JSON" ]]; then
  echo "ERROR: coverage JSON not found at $COV_JSON" >&2
  exit 1
fi

# kcov JSON contains a key like: "percent_covered": "87.50"
PERCENT=$(grep -oP '"percent_covered":\s*"\K[0-9.]+' "$COV_JSON")
PERCENT_INT=${PERCENT%%.*}   # truncate decimal

echo "Coverage: ${PERCENT}%  (minimum: ${MIN_COVERAGE}%)"

if (( PERCENT_INT < MIN_COVERAGE )); then
  echo "FAIL: coverage ${PERCENT}% is below threshold ${MIN_COVERAGE}%" >&2
  exit 1
fi

echo "PASS: coverage threshold met"

분기 커버리지와 줄 커버리지 비교

접하게 될 주요 커버리지 측정항목은 두 가지입니다.

  • 줄 커버리지 — 이 줄이 한 번이라도 실행되었는가? 쉽게 수치를 높일 수 있습니다. 하나의 테스트가 많은 줄을 실행하면서도 중요한 조건부 경로를 놓칠 수 있기 때문입니다.
  • 분기 커버리지 — 모든 if, case, &&/||의 각 분기가 실행되었는가? 훨씬 강력한 지표입니다. 각 판단의 참인 경우와 거짓인 경우 모두에 대한 테스트가 필요합니다.

kcov는 두 지표를 모두 보고합니다. 핵심은 다음과 같습니다. 줄 커버리지 100%가 분기 커버리지 100%를 의미하지는 않습니다. 다음 스크립트를 생각해 보십시오. 비어 있지 않은 파일을 사용하는 단일 테스트는 모든 줄을 실행하지만, 빈 파일 분기(아래 9번 줄)는 실행되지 않습니다.

#!/usr/bin/env bash
# Illustrates line vs branch coverage gap
set -euo pipefail

check_file() {
  local f="$1"
  if [[ -f "$f" ]]; then        # branch A (true) OR branch B (false)
    local lines
    lines=$(wc -l < "$f")
    if (( lines > 0 )); then    # branch C (true) OR branch D (false)
      echo "File has $lines lines"
    else
      echo "File is empty"     # branch D — unreached if only tested with non-empty file
    fi
  else
    echo "File missing"        # branch B — unreached if only tested with existing file
  fi
}

# Only one test: covers lines 5-10 (4 of 6 branches)
TMPDIR=$(mktemp -d)
trap 'rm -rf "$TMPDIR"' EXIT
echo 'data' > "$TMPDIR/sample.txt"
check_file "$TMPDIR/sample.txt"

# To reach 100% branch coverage you also need:
# check_file "/nonexistent/path"
# check_file "$TMPDIR/empty.txt" (after: touch "$TMPDIR/empty.txt")

CI에서 픽스처와 커버리지 통합하기

모든 요소를 하나로 결합하면 다음과 같습니다. Bash 프로젝트를 위한 견고한 CI 파이프라인은 하나의 스크립트에서 픽스처 설정, kcov를 사용한 테스트 실행, 병합, 임계값 확인을 모두 수행합니다. 이 스크립트가 CI 진입점이 되어 하나의 명령으로 모든 작업을 실행할 수 있습니다.

CI 테스트 실행기의 설계 원칙:

  • 각 테스트 사례는 setup_fixture를 호출하고 trap을 통해 teardown_fixture를 등록합니다.
  • 테스트 대상 스크립트는 가짜 $PATH와 범위가 제한된 환경 변수를 사용하여 호출합니다.
  • kcov가 각 호출을 감싸고 번호가 매겨진 하위 디렉터리에 결과를 기록합니다.
  • 모든 테스트가 끝나면 kcov가 결과를 병합하고 임계값 스크립트가 빌드를 통과시킬지 결정합니다.
  • 테스트 또는 커버리지 확인 중 하나라도 실패하면 CI 실행기가 0이 아닌 종료 상태를 반환합니다.
#!/usr/bin/env bash
# ci_runner.sh — full fixture + coverage pipeline entry point
set -euo pipefail

SRC="./src/deploy.sh"
COV_ROOT="$(mktemp -d)/coverage"
trap 'rm -rf "$COV_ROOT"' EXIT
mkdir -p "$COV_ROOT"

PASS=0
FAIL=0
RUN_NUM=0

run_test() {
  local name="$1" test_fn="$2"
  local fixture
  fixture=$(mktemp -d)
  local cov_out="$COV_ROOT/run_$((++RUN_NUM))"

  if (
    trap 'rm -rf "$fixture"' EXIT
    export FIXTURE="$fixture"
    # Fake bin directory shadowing real tools
    mkdir -p "$fixture/bin"
    export PATH="$fixture/bin:$PATH"
    "$test_fn" "$fixture"
  ); then
    echo "PASS: $name"
    (( PASS++ )) || true
  else
    echo "FAIL: $name"
    (( FAIL++ )) || true
  fi
}

# Example test function
test_happy_path() {
  local fx="$1"
  mkdir -p "$fx/dist"
  echo 'app.js' > "$fx/dist/index.js"
  # Would normally run: kcov "$cov_out" "$SRC" --env=staging "$fx"
  echo "[test] happy path executed in $fx"
}

run_test 'happy_path' test_happy_path

echo "Results: $PASS passed, $FAIL failed"
(( FAIL == 0 ))

지식 확인: 가짜 PATH 기법

Bash 테스트 픽스처에서 사용하는 가짜 PATH 기법에 대한 이해도를 확인해 보십시오.

복습: 픽스처, 임시 환경, 커버리지

이번 레슨에서는 신뢰할 수 있고 격리된 Bash 테스트에 필요한 전체 도구 모음을 다뤘습니다.

  • 임시 디렉터리 — mktemp -d와 trap ... EXIT를 함께 사용하면 테스트가 어떤 방식으로 끝나든 자동 정리가 보장됩니다.
  • 픽스처 구조 — setup_fixture와 teardown_fixture 쌍이 실제 스크립트 입력을 본뜬 최소 디렉터리 트리를 만들고 삭제합니다.
  • 가짜 PATH — 스텁 실행 파일을 $FIXTURE/bin/에 배치하고 이를 $PATH 앞에 추가하면 시스템 바이너리를 건드리지 않고 curl, aws, docker 또는 어떤 외부 도구에 대한 호출도 가로챌 수 있습니다.
  • 환경 범위 지정 — 테스트 대상 스크립트를 하위 셸(() 또는 env -i)에서 실행하면 변경된 변수가 테스트 실행기로 유출되지 않습니다.
  • 검증 — 작은 도우미 함수(assert_eq, assert_file_exists, assert_contains)가 명확한 성공/실패 출력과 의미 있는 오류 메시지를 생성합니다.
  • kcov 커버리지 — 소스 변경 없이 스크립트 실행을 감싸며 줄 커버리지와 분기 커버리지에 대한 HTML 및 JSON 보고서를 생성합니다.
  • 병합과 임계값 — --merge로 여러 kcov 실행 결과를 결합하고 JSON을 분석한 다음, 커버리지가 최소 기준 아래로 떨어지면 CI를 실패 처리합니다.
  • 분기 커버리지와 줄 커버리지 — 항상 분기 커버리지를 목표로 하십시오. 줄 커버리지만 사용하면 조건문의 전체 경로를 놓쳐 근거 없이 안심할 수 있습니다.

이러한 기법을 사용하면 Bash 테스트도 컴파일 언어의 테스트만큼 엄격해집니다.

자주 묻는 질문

“테스트 픽스처, 임시 환경 및 커버리지” 강의는 무료인가요?

네 — “테스트 픽스처, 임시 환경 및 커버리지” 전체 내용을 이 웹사이트에서 무료로 읽을 수 있습니다. 인터랙티브하게 실습하려면(내장 코드 에디터와 24/7 AI 튜터), CoddyKit PRO로 업그레이드하면 DevOps Bootcamp 강의 전체를 잠금 해제할 수 있습니다. DevOps Bootcamp 강의에는 총 4개의 강의가 포함되어 있습니다.

“테스트 픽스처, 임시 환경 및 커버리지”에서 뭘 배우나요?

격리된 테스트 픽스처를 만들고 테스트가 실제로 실행하는 스크립트 분기를 측정합니다. 브라우저에서 직접 실행하는 실습 코드로 DevOps Bootcamp을(를) 배우며, 24/7 AI 튜터가 강의를 진행하면서 질문에 답변해줍니다.

DevOps Bootcamp을(를) 시작하는 데 경험이 필요한가요?

사전 경험은 필요하지 않습니다. CoddyKit의 DevOps Bootcamp은(는) 초급자부터 고급 학습자까지를 위해 구성되어 있으므로, 여기서 시작하거나 처음부터 시작할 수 있으며 자신의 속도대로 진행할 수 있습니다. 이것은 4개 중 3번째 강의입니다.

“테스트 픽스처, 임시 환경 및 커버리지” 강의는 얼마나 걸리나요?

대부분의 CoddyKit 강의는 약 5~10분이 소요됩니다. 각 강의는 간결하고 인터랙티브하여 꾸준한 진행이 가능하며, 웹과 앱에서 중단한 부분부터 바로 시작할 수 있습니다.

이 DevOps Bootcamp 강의에서 코드를 작성하고 실행할 수 있나요?

네. 모든 DevOps Bootcamp 강의에는 내장 코드 에디터가 포함되어 있으므로, 브라우저에서 바로 실제 코드를 작성하고 실행한 후 즉시 AI 피드백을 받을 수 있습니다 — 로컬 설정이 필요 없습니다.

이 강의의 모든 강의

  1. Bats-core로 함수 단위 테스트
  2. 명령 모킹 및 외부 도구 스텁 처리
  3. 테스트 픽스처, 임시 환경 및 커버리지
  4. CI 파이프라인에서 셸 테스트 실행
← DevOps Bootcamp(으)로 돌아가기