0Pricing
Linux Command Line & Bash Scripting Mastery · บทเรียน

การจำลองคำสั่งและการทำเครื่องมือภายนอกเป็นสตับ

แทนที่ PATH และกำหนดไบนารีปลอมเพื่อทดสอบสคริปต์โดยไม่แตะต้องระบบจริง

การจำลองคำสั่งและการทำเครื่องมือภายนอกเป็นสตับ เป็นบทเรียน Linux Command Line & Bash Scripting Mastery ฟรีบน CoddyKit นี่คือบทเรียนที่ 2 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน Linux Command Line & Bash Scripting Mastery และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส Linux Command Line & Bash Scripting Mastery มีบทเรียนทั้งหมด 4 บทเรียน

เหตุใดจึงต้องจำลองคำสั่งในการทดสอบ Bash

เมื่อคุณทดสอบสคริปต์ Bash ที่เรียกใช้ curl, aws, git หรือเครื่องมือภายนอกใด ๆ คุณจะพบปัญหาว่า การเรียกใช้จริงอาจเข้าถึงเครือข่าย แก้ไขสถานะ มีค่าใช้จ่าย หรือทำงานล้มเหลวในสภาพแวดล้อม CI ที่ไม่ได้ติดตั้งเครื่องมือเหล่านั้น

การจำลอง หมายถึงการแทนที่คำสั่งจริงด้วยคำสั่งปลอมที่คุณควบคุมได้ คำสั่งปลอมของคุณ (หรือตัวแทนจำลอง) จะคืนผลลัพธ์และรหัสการออกที่คาดเดาได้ ทำให้การทดสอบรวดเร็ว แยกเป็นอิสระ และทำซ้ำได้

  • ไม่ต้องเข้าถึงเครือข่ายหรือระบบคลาวด์
  • การทดสอบทำงานในระดับมิลลิวินาทีแทนที่จะเป็นวินาที
  • คุณสามารถจำลองข้อผิดพลาดที่ทำให้เกิดขึ้นได้ยากบนระบบจริง
  • ไปป์ไลน์ CI สะอาดและไม่ขึ้นต่อกับสิ่งอื่น

Bash มีกลไกที่เรียบง่ายอย่างน่าประหลาดใจสำหรับการทำเช่นนี้ เพียงวางไบนารีปลอมไว้ในตำแหน่งก่อนหน้าไบนารีจริงบน $PATH

การทำงานของการค้นหา PATH

เมื่อเชลล์เรียกใช้คำสั่ง เช่น curl เชลล์จะค้นหาแต่ละไดเรกทอรีใน $PATH จากซ้ายไปขวา และเรียกใช้รายการแรกที่พบ

ดังนั้น หากคุณเพิ่มไดเรกทอรีที่มีสคริปต์ curl ของคุณเองไว้ด้านหน้า เชลล์จะไม่ไปถึง /usr/bin/curl

รูปแบบการแทนที่:

  1. สร้างไดเรกทอรีชั่วคราว (ไดเรกทอรีไบนารีของตัวแทนจำลอง)
  2. เขียนไฟล์ที่เรียกใช้งานได้ปลอมโดยใช้ชื่อเดียวกับคำสั่งจริง
  3. เพิ่มไดเรกทอรีนั้นไว้ด้านหน้าของ PATH
  4. เรียกใช้สคริปต์ที่กำลังทดสอบ — สคริปต์จะเรียกตัวแทนจำลองของคุณ ไม่ใช่ไบนารีจริง
  5. ล้างไดเรกทอรีชั่วคราวหลังการทดสอบ

วิธีนี้ทำงานได้โดยไม่ต้องมีสิทธิ์ root ไม่ต้องแก้ไขไฟล์ระบบ และไม่ต้องใช้เฟรมเวิร์กพิเศษ

การสร้างไดเรกทอรีตัวแทนจำลอง

รูปแบบมาตรฐานใช้ mktemp -d เพื่อสร้างไดเรกทอรีชั่วคราวแยกเฉพาะสำหรับตัวแทนจำลอง การทดสอบหรือชุดการทดสอบแต่ละรายการจะมีไดเรกทอรีของตนเอง เพื่อป้องกันการปนเปื้อนข้ามการทดสอบ

เมื่อการทดสอบเสร็จสิ้น ให้ลบไดเรกทอรีด้วย rm -rf การใช้ trap ช่วยให้ล้างข้อมูลได้แม้การทดสอบจะจบก่อนกำหนดเนื่องจากข้อผิดพลาด

#!/usr/bin/env bash
# Setup a stub bin directory for testing

# Create the temp dir
STUB_BIN=$(mktemp -d)

# Always clean up on exit (success, error, or signal)
trap 'rm -rf "$STUB_BIN"' EXIT

# Prepend it to PATH so our stubs take priority
export PATH="$STUB_BIN:$PATH"

echo "Stub bin: $STUB_BIN"
echo "PATH starts with: ${PATH%%:*}"

# Your tests would go here...
echo "Tests complete."

การเขียนตัวแทนจำลองแรกของคุณ

ตัวแทนจำลองคือไฟล์ที่เรียกใช้งานได้ซึ่งมีชื่อเดียวกับคำสั่งที่คุณต้องการแทนที่ โดยจะแสดงผลลัพธ์ตามที่สคริปต์ที่กำลังทดสอบคาดไว้ และจบการทำงานด้วยรหัสที่คุณเลือก

กฎสำคัญสำหรับตัวแทนจำลอง:

  • ไฟล์ต้อง เรียกใช้งานได้ (chmod +x)
  • ต้องมีบรรทัด shebang (#!/usr/bin/env bash)
  • แสดงผลลัพธ์ที่สคริปต์จริงของคุณจะนำไปประมวลผล
  • ใช้ exit 0 เมื่อสำเร็จ และใช้ค่าที่ไม่ใช่ศูนย์สำหรับความล้มเหลวที่จำลองขึ้น
#!/usr/bin/env bash
# Create a stub for 'curl' that returns a fake HTTP response

STUB_BIN=$(mktemp -d)
trap 'rm -rf "$STUB_BIN"' EXIT
export PATH="$STUB_BIN:$PATH"

# Write the stub
cat > "$STUB_BIN/curl" << 'EOF'
#!/usr/bin/env bash
# Fake curl: always returns a 200 OK with a JSON body
echo '{"status": "ok", "version": "1.2.3"}'
exit 0
EOF
chmod +x "$STUB_BIN/curl"

# Verify the stub is found before the real curl
which curl
curl https://example.com/api/version

การทดสอบสคริปต์ที่เรียกใช้ curl

ตอนนี้ลองนำทุกอย่างมารวมกัน สมมติว่าคุณมีสคริปต์นำไปใช้งานที่เรียกใช้ curl เพื่อตรวจสอบจุดปลายทางสถานะสุขภาพ แล้วจบการทำงานด้วยข้อผิดพลาดหากบริการไม่อยู่ในสถานะปกติ คุณต้องการทดสอบทั้งเส้นทางที่ทำงานสำเร็จและเส้นทางที่ล้มเหลว โดยไม่ต้องใช้เซิร์ฟเวอร์จริง

#!/usr/bin/env bash
# Script under test: check_health.sh
# It calls curl and checks the returned JSON

check_health() {
  local url="$1"
  local response
  response=$(curl -sf "$url")
  if [[ "$response" == *'"healthy":true'* ]]; then
    echo "Service is UP"
    return 0
  else
    echo "Service is DOWN" >&2
    return 1
  fi
}

# ---- Test harness ----
STUB_BIN=$(mktemp -d)
trap 'rm -rf "$STUB_BIN"' EXIT
export PATH="$STUB_BIN:$PATH"

# Happy path stub
cat > "$STUB_BIN/curl" << 'EOF'
#!/usr/bin/env bash
echo '{"healthy":true}'
EOF
chmod +x "$STUB_BIN/curl"

check_health "http://fake-host/health" && echo "PASS: healthy response"

การจำลองความล้มเหลวของคำสั่ง

การใช้งานสตับที่มีประโยชน์อย่างยิ่งอย่างหนึ่งคือการจำลองความล้มเหลวที่ทำให้เกิดซ้ำได้ยากเมื่อใช้เครื่องมือจริง เช่น การหมดเวลาของเครือข่าย ข้อผิดพลาดด้านสิทธิ์ ดิสก์เต็ม หรือเอพีไอระยะไกลส่งค่ากลับเป็น 500

หากต้องการจำลองความล้มเหลว เพียงทำให้สตับจบการทำงานด้วยรหัสที่ไม่ใช่ศูนย์ นอกจากนี้ คุณยังสามารถเขียนไปยัง stderr ให้เหมือนกับที่คำสั่งจริงทำได้ เพื่อให้การจัดการข้อผิดพลาดของสคริปต์ถูกทดสอบอย่างทั่วถึง

#!/usr/bin/env bash
# Test that check_health handles a curl failure gracefully

check_health() {
  local url="$1"
  local response
  # -f makes curl exit non-zero on HTTP error; -s silences progress
  if ! response=$(curl -sf "$url" 2>/dev/null); then
    echo "ERROR: could not reach $url" >&2
    return 1
  fi
  echo "OK: $response"
}

STUB_BIN=$(mktemp -d)
trap 'rm -rf "$STUB_BIN"' EXIT
export PATH="$STUB_BIN:$PATH"

# Failure stub — simulates a network error (curl exit code 6 = could not resolve host)
cat > "$STUB_BIN/curl" << 'EOF'
#!/usr/bin/env bash
echo 'curl: (6) Could not resolve host: fake-host' >&2
exit 6
EOF
chmod +x "$STUB_BIN/curl"

if ! check_health "http://fake-host/health"; then
  echo "PASS: failure path handled correctly"
fi

การบันทึกการเรียกใช้สตับเพื่อตรวจสอบ

บางครั้งคุณจำเป็นต้องตรวจสอบไม่ใช่แค่สิ่งที่สคริปต์แสดงผล แต่รวมถึงวิธีที่สคริปต์เรียกใช้เครื่องมือภายนอกด้วย เช่น อาร์กิวเมนต์ที่ส่งไป จำนวนครั้งที่เรียกใช้ หรือลำดับการเรียกใช้ สตับแบบสายลับจะบันทึกการเรียกใช้ลงในไฟล์

หลังการทดสอบ ชุดเครื่องมือทดสอบจะอ่านไฟล์บันทึกและตรวจสอบเนื้อหาของไฟล์ วิธีนี้ช่วยให้คุณตรวจสอบได้ถึงระดับอาร์กิวเมนต์โดยไม่ต้องใช้เฟรมเวิร์กพิเศษใด ๆ

#!/usr/bin/env bash
# Spy stub: record every invocation of 'aws' to a log file

STUB_BIN=$(mktemp -d)
CALL_LOG=$(mktemp)
trap 'rm -rf "$STUB_BIN" "$CALL_LOG"' EXIT
export PATH="$STUB_BIN:$PATH"
export CALL_LOG   # make it available inside the stub

cat > "$STUB_BIN/aws" << 'EOF'
#!/usr/bin/env bash
# Append all arguments to the call log
echo "aws $*" >> "$CALL_LOG"
# Return fake S3 output
echo "upload: ./report.pdf to s3://my-bucket/report.pdf"
exit 0
EOF
chmod +x "$STUB_BIN/aws"

# Simulate the script under test calling aws s3 cp
aws s3 cp report.pdf s3://my-bucket/report.pdf
aws s3 cp logs.tar.gz s3://my-bucket/logs.tar.gz

# Verify calls were made with expected arguments
echo "--- Recorded calls ---"
cat "$CALL_LOG"
grep -q 's3://my-bucket/report.pdf' "$CALL_LOG" && echo "PASS: S3 upload verified"

การสร้างสตับสำหรับหลายคำสั่งพร้อมกัน

สคริปต์จริงมักเรียกใช้เครื่องมือภายนอกหลายรายการ คุณสามารถสร้างสตับทั้งหมดไว้ในไดเรกทอรี STUB_BIN เดียวกันได้ ไฟล์สตับแต่ละไฟล์ทำงานเป็นอิสระและสามารถส่งผลลัพธ์กับรหัสจบการทำงานที่แตกต่างกันได้

ทำให้สตับมีขนาดเล็กที่สุด โดยส่งกลับเฉพาะสิ่งที่สคริปต์ที่กำลังทดสอบนำไปแยกวิเคราะห์จริง ๆ ไม่จำเป็นต้องจำลองแฟล็กทุกตัว ให้จำลองเพียงส่วนย่อยที่สคริปต์ของคุณใช้งาน

#!/usr/bin/env bash
# Stub both 'git' and 'docker' for a release script test

STUB_BIN=$(mktemp -d)
trap 'rm -rf "$STUB_BIN"' EXIT
export PATH="$STUB_BIN:$PATH"

# Stub git: pretend we are on tag v2.1.0
cat > "$STUB_BIN/git" << 'EOF'
#!/usr/bin/env bash
case "$*" in
  *"describe --tags"*) echo "v2.1.0" ;;
  *"rev-parse HEAD"*)  echo "abc1234" ;;
  *) echo "[git stub] unhandled: $*" >&2 ; exit 1 ;;
esac
EOF
chmod +x "$STUB_BIN/git"

# Stub docker: pretend build and push succeed
cat > "$STUB_BIN/docker" << 'EOF'
#!/usr/bin/env bash
echo "[docker stub] $*"
exit 0
EOF
chmod +x "$STUB_BIN/docker"

# Simulate the release logic
VERSION=$(git describe --tags)
SHA=$(git rev-parse HEAD)
echo "Building image for version=$VERSION sha=$SHA"
docker build -t "myapp:$VERSION" .
docker push "myapp:$VERSION"

การใช้ฟังก์ชันเป็นสตับ (ไม่ต้องใช้ไฟล์)

สำหรับกรณีง่าย ๆ คุณไม่จำเป็นต้องเขียนไฟล์เลย สามารถกำหนดฟังก์ชันเชลล์ที่มีชื่อเดียวกับคำสั่งได้ เนื่องจากระบบจะค้นหาฟังก์ชันก่อนค้นหาใน PATH ฟังก์ชันจึงมีลำดับความสำคัญโดยอัตโนมัติ

วิธีนี้เป็นแนวทางที่รวดเร็วที่สุดสำหรับการทดสอบหน่วยของสคริปต์ที่โหลดเข้ามา อย่างไรก็ตาม สตับแบบฟังก์ชันจะทำงานได้เฉพาะภายในกระบวนการเชลล์เดียวกันเท่านั้น โดยจะไม่ปรากฏในเชลล์ย่อยที่สร้างด้วย bash -c อย่างชัดเจน หรือในกระบวนการที่ทำงานอยู่เบื้องหลัง สำหรับกรณีเหล่านี้ ให้ใช้แนวทางแบบใช้ไฟล์

#!/usr/bin/env bash
# Source the script under test (a small helper library)
source_under_test() {
  # Inline the logic we want to test
  get_instance_id() {
    # Would normally call: curl http://169.254.169.254/latest/meta-data/instance-id
    curl -sf http://169.254.169.254/latest/meta-data/instance-id
  }
}
source_under_test

# Override curl with a shell function stub
curl() {
  echo "i-0abc123def456"
  return 0
}
# Export is NOT needed — function is visible in same shell

# Run the function under test
result=$(get_instance_id)
[[ "$result" == "i-0abc123def456" ]] && echo "PASS: instance ID returned" || echo "FAIL"

การส่งออกฟังก์ชันไปยังเชลล์ย่อย

เมื่อสคริปต์ที่กำลังทดสอบเปิดเชลล์ย่อย (เช่น bash script.sh หรือไปป์ไลน์) สตับฟังก์ชันเชลล์ที่กำหนดไว้ในกระบวนการแม่จะไม่ถูกสืบทอดโดยค่าเริ่มต้น คุณมีสองทางเลือก:

  • ใช้ export -f function_name เพื่อส่งออกฟังก์ชัน ซึ่งจะทำให้ฟังก์ชันพร้อมใช้งานในกระบวนการ bash ลูก
  • หรือใช้สตับแบบไฟล์ในไดเรกทอรี STUB_BIN ซึ่งทำงานได้เสมอแม้อยู่คนละขอบเขตกระบวนการ

export -f ดูเรียบง่ายและสวยงาม แต่ทำงานได้เฉพาะกับ bash (ไม่ใช่ sh หรือเชลล์อื่น) ในสภาพแวดล้อม CI ที่ใช้หลายภาษา ควรเลือกใช้สตับแบบไฟล์

#!/usr/bin/env bash
# Demonstrate export -f for subshell-visible function stubs

# Define the stub in the current shell
curl() {
  echo '{"status":"ok"}'
  return 0
}
# Export the function so child bash processes inherit it
export -f curl

# Verify the stub works in a subshell
bash -c '
  response=$(curl -sf http://api.example.com/status)
  echo "Subshell got: $response"
'

# Without export -f, the subshell would call the real curl
# (or fail if curl is not installed)

การผสานสตับเข้ากับเฟรมเวิร์กการทดสอบ (BATS)

เมื่อใช้ BATS (ระบบทดสอบอัตโนมัติของ Bash) ให้เตรียมสตับในฮุก setup() และล้างข้อมูลใน teardown() BATS จะรีเซ็ตสภาพแวดล้อมระหว่างการทดสอบ ดังนั้นการทดสอบแต่ละครั้งจะได้รับไดเรกทอรีสตับใหม่

ตัวแปรของ BATS เช่น $BATS_TEST_TMPDIR จะจัดเตรียมไดเรกทอรีชั่วคราวแยกสำหรับการทดสอบแต่ละครั้งให้โดยอัตโนมัติ ให้ใช้ตัวแปรนี้แทน mktemp -d เพื่อให้โค้ดสะอาดยิ่งขึ้น

#!/usr/bin/env bats
# File: test_deploy.bats
# Run with: bats test_deploy.bats

setup() {
  # BATS provides a unique tmpdir per test
  export STUB_BIN="$BATS_TEST_TMPDIR/stub_bin"
  mkdir -p "$STUB_BIN"
  export PATH="$STUB_BIN:$PATH"

  # Default stub: healthy service
  cat > "$STUB_BIN/curl" << 'EOF'
#!/usr/bin/env bash
echo '{"healthy":true}'
EOF
  chmod +x "$STUB_BIN/curl"
}

teardown() {
  # BATS auto-removes BATS_TEST_TMPDIR, but explicit is safer
  rm -rf "$STUB_BIN"
}

@test "deploy succeeds when service is healthy" {
  run bash deploy.sh
  [ "$status" -eq 0 ]
  [[ "$output" == *"Deploy complete"* ]]
}

@test "deploy aborts when service is down" {
  # Override the stub for this specific test
  echo -e '#!/usr/bin/env bash\nexit 1' > "$STUB_BIN/curl"
  chmod +x "$STUB_BIN/curl"

  run bash deploy.sh
  [ "$status" -ne 0 ]
}

ตรวจสอบความรู้: การจำลองคำสั่งใน Bash

ทดสอบความเข้าใจของคุณเกี่ยวกับการจำลองคำสั่งและรูปแบบสตับใน Bash

นักพัฒนาคนหนึ่งเขียนการทดสอบที่กำหนดฟังก์ชันเชลล์ชื่อ aws เพื่อแทนที่ AWS CLI จริง การทดสอบทำงานได้ตามปกติเมื่อเรียกโดยตรงในเทอร์มินัล แต่เมื่อไปป์ไลน์ CI เรียกใช้สคริปต์ที่กำลังทดสอบด้วย bash deploy.sh ระบบกลับเพิกเฉยต่อสตับและเรียกใช้คำสั่ง aws จริง

วิธีแก้ไขที่ถูกต้องคืออะไร

สรุป: การจำลองคำสั่งและการสร้างสตับสำหรับเครื่องมือภายนอก

คุณได้เรียนรู้ชุดเครื่องมือครบถ้วนสำหรับแทนที่คำสั่งจริงด้วยสิ่งจำลองที่ควบคุมได้ระหว่างการทดสอบสคริปต์ Bash

เทคนิคหลักที่ครอบคลุม:

  • การเพิ่มไดเรกทอรีไว้หน้าสุดของ PATH — สร้างไดเรกทอรี STUB_BIN ด้วย mktemp -d เขียนไฟล์สตับที่เรียกใช้งานได้ลงไป แล้วเพิ่มไดเรกทอรีนี้ไว้หน้าสุดของ PATH
  • รหัสจบการทำงานของสตับ — ส่งกลับ 0 เมื่อสำเร็จ และส่งค่าที่ไม่ใช่ศูนย์เพื่อจำลองความล้มเหลวเฉพาะแบบ (ข้อผิดพลาดเครือข่าย การถูกปฏิเสธสิทธิ์ และอื่น ๆ)
  • สตับแบบสายลับ — เพิ่มอาร์กิวเมนต์ต่อท้ายไฟล์บันทึกภายในสตับ เพื่อตรวจสอบว่าสคริปต์เรียกใช้เครื่องมือภายนอกอย่างไร
  • สตับหลายรายการ — วางไฟล์สตับหลายไฟล์ไว้ใน STUB_BIN เดียวกัน เพื่อจำลองระบบนิเวศของส่วนพึ่งพาทั้งหมดพร้อมกัน
  • สตับแบบฟังก์ชัน — กำหนดฟังก์ชันเชลล์ที่มีชื่อเดียวกับคำสั่งเพื่อจำลองภายในกระบวนการเดียวกัน ใช้ export -f เพื่อให้เข้าถึงกระบวนการ Bash ลูกได้
  • การผสานกับ BATS — ใช้ฮุก setup()/teardown() และ $BATS_TEST_TMPDIR เพื่อแยกสภาพแวดล้อมของการทดสอบแต่ละครั้งอย่างสะอาด

ให้ใช้ trap '...' EXIT เสมอ เพื่อรับประกันว่าการล้างสตับจะเกิดขึ้นไม่ว่าผลการทดสอบจะเป็นอย่างไร ทำให้สตับมีขนาดเล็กที่สุด โดยส่งกลับเฉพาะสิ่งที่สคริปต์นำไปแยกวิเคราะห์จริง ๆ สตับแบบไฟล์เป็นตัวเลือกที่พกพาได้ดีที่สุดสำหรับไปป์ไลน์ CI

คำถามที่พบบ่อย

บทเรียน “การจำลองคำสั่งและการทำเครื่องมือภายนอกเป็นสตับ” ฟรีหรือไม่

ใช่ — ข้อความเต็มของ “การจำลองคำสั่งและการทำเครื่องมือภายนอกเป็นสตับ” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส Linux Command Line & Bash Scripting Mastery ให้อัปเกรดเป็น CoddyKit PRO คอร์ส Linux Command Line & Bash Scripting Mastery มีบทเรียนทั้งหมด 4 บทเรียน

คุณจะเรียนรู้อะไรในบทเรียน “การจำลองคำสั่งและการทำเครื่องมือภายนอกเป็นสตับ”

แทนที่ PATH และกำหนดไบนารีปลอมเพื่อทดสอบสคริปต์โดยไม่แตะต้องระบบจริง คุณปฏิบัติ Linux Command Line & Bash Scripting Mastery ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน

คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน Linux Command Line & Bash Scripting Mastery หรือไม่

ไม่จำเป็นต้องมีประสบการณ์มาก่อน Linux Command Line & Bash Scripting Mastery บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 2 จากทั้งหมด 4 บทเรียน

บทเรียน “การจำลองคำสั่งและการทำเครื่องมือภายนอกเป็นสตับ” ใช้เวลานานแค่ไหน

บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย

ฉันเขียนและรันโค้ดในบทเรียน Linux Command Line & Bash Scripting Mastery นี้ได้ไหม

ได้ บทเรียน Linux Command Line & Bash Scripting Mastery ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ

บทเรียนทั้งหมดในหลักสูตรนี้

  1. การทดสอบฟังก์ชันแบบยูนิตด้วย Bats-core
  2. การจำลองคำสั่งและการทำเครื่องมือภายนอกเป็นสตับ
  3. ฟิกซ์เจอร์ สภาพแวดล้อมชั่วคราว และความครอบคลุม
  4. การเรียกใช้การทดสอบ Shell ในไปป์ไลน์ CI
← กลับไปที่ Linux Command Line & Bash Scripting Mastery