การจำลองคำสั่งและการทำเครื่องมือภายนอกเป็นสตับ
แทนที่ PATH และกำหนดไบนารีปลอมเพื่อทดสอบสคริปต์โดยไม่แตะต้องระบบจริง
การจำลองคำสั่งและการทำเครื่องมือภายนอกเป็นสตับ เป็นบทเรียน DevOps Bootcamp ฟรีบน CoddyKit นี่คือบทเรียนที่ 2 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน DevOps Bootcamp และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส DevOps Bootcamp มีบทเรียนทั้งหมด 4 บทเรียน
เหตุใดจึงต้องจำลองคำสั่งในการทดสอบ Bash
เมื่อคุณทดสอบสคริปต์ Bash ที่เรียกใช้ curl, aws, git หรือเครื่องมือภายนอกใด ๆ คุณจะพบปัญหาว่า การเรียกใช้จริงอาจเข้าถึงเครือข่าย แก้ไขสถานะ มีค่าใช้จ่าย หรือทำงานล้มเหลวในสภาพแวดล้อม CI ที่ไม่ได้ติดตั้งเครื่องมือเหล่านั้น
การจำลอง หมายถึงการแทนที่คำสั่งจริงด้วยคำสั่งปลอมที่คุณควบคุมได้ คำสั่งปลอมของคุณ (หรือตัวแทนจำลอง) จะคืนผลลัพธ์และรหัสการออกที่คาดเดาได้ ทำให้การทดสอบรวดเร็ว แยกเป็นอิสระ และทำซ้ำได้
- ไม่ต้องเข้าถึงเครือข่ายหรือระบบคลาวด์
- การทดสอบทำงานในระดับมิลลิวินาทีแทนที่จะเป็นวินาที
- คุณสามารถจำลองข้อผิดพลาดที่ทำให้เกิดขึ้นได้ยากบนระบบจริง
- ไปป์ไลน์ CI สะอาดและไม่ขึ้นต่อกับสิ่งอื่น
Bash มีกลไกที่เรียบง่ายอย่างน่าประหลาดใจสำหรับการทำเช่นนี้ เพียงวางไบนารีปลอมไว้ในตำแหน่งก่อนหน้าไบนารีจริงบน $PATH
การทำงานของการค้นหา PATH
เมื่อเชลล์เรียกใช้คำสั่ง เช่น curl เชลล์จะค้นหาแต่ละไดเรกทอรีใน $PATH จากซ้ายไปขวา และเรียกใช้รายการแรกที่พบ
ดังนั้น หากคุณเพิ่มไดเรกทอรีที่มีสคริปต์ curl ของคุณเองไว้ด้านหน้า เชลล์จะไม่ไปถึง /usr/bin/curl
รูปแบบการแทนที่:
- สร้างไดเรกทอรีชั่วคราว (ไดเรกทอรีไบนารีของตัวแทนจำลอง)
- เขียนไฟล์ที่เรียกใช้งานได้ปลอมโดยใช้ชื่อเดียวกับคำสั่งจริง
- เพิ่มไดเรกทอรีนั้นไว้ด้านหน้าของ
PATH - เรียกใช้สคริปต์ที่กำลังทดสอบ — สคริปต์จะเรียกตัวแทนจำลองของคุณ ไม่ใช่ไบนารีจริง
- ล้างไดเรกทอรีชั่วคราวหลังการทดสอบ
วิธีนี้ทำงานได้โดยไม่ต้องมีสิทธิ์ 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) และปลดล็อคส่วนที่เหลือของคอร์ส DevOps Bootcamp ให้อัปเกรดเป็น CoddyKit PRO คอร์ส DevOps Bootcamp มีบทเรียนทั้งหมด 4 บทเรียน
คุณจะเรียนรู้อะไรในบทเรียน “การจำลองคำสั่งและการทำเครื่องมือภายนอกเป็นสตับ”
แทนที่ PATH และกำหนดไบนารีปลอมเพื่อทดสอบสคริปต์โดยไม่แตะต้องระบบจริง คุณปฏิบัติ DevOps Bootcamp ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน
คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน DevOps Bootcamp หรือไม่
ไม่จำเป็นต้องมีประสบการณ์มาก่อน DevOps Bootcamp บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 2 จากทั้งหมด 4 บทเรียน
บทเรียน “การจำลองคำสั่งและการทำเครื่องมือภายนอกเป็นสตับ” ใช้เวลานานแค่ไหน
บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย
ฉันเขียนและรันโค้ดในบทเรียน DevOps Bootcamp นี้ได้ไหม
ได้ บทเรียน DevOps Bootcamp ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ
บทเรียนทั้งหมดในหลักสูตรนี้
- การทดสอบฟังก์ชันแบบยูนิตด้วย Bats-core
- การจำลองคำสั่งและการทำเครื่องมือภายนอกเป็นสตับ
- ฟิกซ์เจอร์ สภาพแวดล้อมชั่วคราว และความครอบคลุม
- การเรียกใช้การทดสอบ Shell ในไปป์ไลน์ CI