Penguasaan Baris Perintah Linux & Penskripan Bash · Pelajaran

Lekapan Ujian, Persekitaran Sementara dan Liputan

Bina lekapan ujian terpencil dan ukur cabang skrip yang benar-benar dilalui oleh ujian anda

Pelajaran 3 daripada 413 langkah

Lekapan Ujian, Persekitaran Sementara dan Liputan ialah pelajaran Penguasaan Baris Perintah Linux & Penskripan Bash percuma di CoddyKit. Ini ialah pelajaran 3 daripada 4. Anda boleh membaca keseluruhan pelajaran di bawah secara percuma — kemudian berlatih secara praktikal dalam pelayar menggunakan penyunting kod terbina dalam dan tutor kecerdasan buatan 24/7. Pelajaran ini merupakan sebahagian daripada laluan pembelajaran Penguasaan Baris Perintah Linux & Penskripan Bash, dan kemajuan anda disegerakkan merentas web serta aplikasi CoddyKit. Kursus Penguasaan Baris Perintah Linux & Penskripan Bash merangkumi sejumlah 4 pelajaran.

Mengapa Lekapan Ujian dan Pengasingan Penting

Apabila menguji skrip Bash, risiko terbesar ialah kesan sampingan: ujian anda secara tidak sengaja mengubah suai fail sebenar, pangkalan data sebenar atau keadaan sistem sebenar. Ujian yang lulus pada komputer anda tetapi merosakkan data pengeluaran adalah lebih buruk daripada tiada ujian langsung.

Penyelesaiannya ialah lekapan ujian — persekitaran terkawal dan boleh dilupuskan yang mencerminkan keadaan sebenar tanpa menyentuh apa-apa yang sebenar. Lekapan yang baik memberikan anda:

  • Kebolehulangan — ujian menghasilkan keputusan yang sama pada setiap pelaksanaan
  • Pengasingan — ujian tidak mengganggu satu sama lain atau hos
  • Keselamatan — operasi yang memusnahkan hanya menyentuh data yang boleh dibuang
  • Kelajuan — tiada panggilan rangkaian atau I/O berat kecuali benar-benar perlu

Dalam ujian Bash, lekapan biasanya terdiri daripada direktori sementara yang diisi dengan fail yang diketahui, fail boleh laku olok-olok yang diletakkan di awal $PATH dan pemboleh ubah persekitaran yang skopnya terhad kepada proses ujian.

Mencipta dan Membersihkan Direktori Sementara

Corak standard untuk direktori sementara bagi setiap ujian menggunakan mktemp -d, yang mencipta direktori unik dalam /tmp dan mencetak laluannya. Anda menyimpan laluan tersebut dan mendaftarkan trap untuk membuangnya secara automatik apabila shell keluar — walaupun berlaku kegagalan.

Idiom dua baris ini hendaklah muncul dalam setiap fail ujian yang menyentuh sistem fail:

#!/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'

Menstrukturkan Pepohon Direktori Lekapan Ujian

Lekapan yang distrukturkan dengan baik mencerminkan susun atur direktori yang benar-benar dijangka oleh skrip yang sedang diuji. Anggaplah ia sebagai akar projek palsu bersaiz kecil. Fungsi penyediaan lekapan mencipta susun atur ini sebelum setiap ujian dan fungsi pembersihan membuangnya.

Amalan utama:

  • Gunakan fungsi setup() yang dipanggil oleh rangka kerja ujian sebelum setiap ujian
  • Gunakan teardown() atau cleanup() yang dijalankan selepas setiap ujian, walaupun berlaku kegagalan
  • Pastikan fail lekapan minimum — hanya perkara yang benar-benar dibaca oleh skrip
  • Namakan fail lekapan secara deskriptif supaya kegagalan mudah didiagnosis
#!/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

Meniru Fail Boleh Laku dengan PATH Palsu

Banyak skrip Bash memanggil alat luaran seperti curl, aws, docker atau git. Dalam ujian, anda tidak mahu menghubungi perkhidmatan sebenar, jadi anda menggantikan alat tersebut dengan fail boleh laku olok-olok.

Tekniknya mudah:

  1. Cipta direktori sementara bin/ di dalam lekapan anda
  2. Tulis skrip shell kecil di situ dengan nama yang sama seperti alat sebenar
  3. Letakkan direktori itu di hadapan $PATH sebelum memanggil skrip yang sedang diuji

Oleh sebab $PATH dicari dari kiri ke kanan, fail olok-olok akan diutamakan. Binari sebenar tidak pernah dipanggil.

#!/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"

Menangkap dan Mengesahkan Output Perintah

Lekapan hanya berguna jika anda boleh mengesahkan perkara yang dilakukan oleh skrip anda. Corak standard ialah:

  • Tangkap stdout/stderr ke dalam pemboleh ubah dengan $() atau penggantian proses
  • Periksa fail log yang ditulis oleh binari olok-olok
  • Semak kod keluar secara eksplisit dengan $? atau logik bersyarat
  • Sahkan bahawa fail tertentu telah dicipta, diubah suai atau dibiarkan tanpa perubahan

Menulis pembantu pengesahan yang kecil dan berfokus menjadikan ujian anda mudah dibaca serta memberikan mesej kegagalan yang tepat apabila sesuatu tidak berjalan dengan betul.

#!/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"

Penskopan Pemboleh Ubah Persekitaran dalam Ujian

Skrip sering membaca pemboleh ubah persekitaran seperti $HOME, $CONFIG_PATH atau $DATABASE_URL. Dalam ujian, anda mesti mengatasi nilai ini tanpa mencemarkan persekitaran sebenar.

Pendekatan paling selamat ialah menjalankan skrip yang sedang diuji dalam subproses dengan hanya pemboleh ubah yang anda tetapkan secara eksplisit. Perintah env membolehkan anda mengosongkan persekitaran dan menambah semula perkara yang diperlukan sahaja:

  • env -i VAR=val ./script.sh — persekitaran yang bersih sepenuhnya
  • (export VAR=val; ./script.sh) — subproses mewarisi persekitaran induk serta pengatasan anda

Menggunakan subproses juga bermakna jika skrip mengubah $IFS, $PWD atau keadaan global lain, perubahan itu tidak akan keluar kembali ke pelancar ujian anda.

#!/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"

Pengenalan kepada kcov untuk Liputan Bash

Liputan menjawab soalan: baris (dan cabang) skrip saya yang manakah sebenarnya dilaksanakan oleh ujian? Nombor liputan yang tinggi tidak menjamin ketepatan, tetapi liputan yang rendah mendedahkan laluan yang belum diuji dan berkemungkinan mengandungi pepijat.

Alat utama untuk liputan Bash ialah kcov. Alat ini berfungsi dengan menginstrumentasikan skrip pada peringkat OS menggunakan PTRACE (Linux) atau dtrace (macOS), jadi tiada perubahan pada kod sumber diperlukan. Alat ini menghasilkan laporan HTML yang menunjukkan baris merah (belum diliputi) dan hijau (telah diliputi).

Penggunaan asas:

  • kcov --include-path=./src coverage-out/ ./src/myscript.sh
  • Buka coverage-out/index.html dalam pelayar untuk memeriksa hasil
  • Dalam CI, huraikan coverage-out/myscript.sh/coverage.json untuk mendapatkan peratusan yang boleh dibaca mesin

Nota: kcov mesti dipasang secara berasingan (brew install kcov pada macOS, apt install kcov pada Ubuntu 20.04+).

Menjalankan kcov terhadap Skrip Sebenar

Berikut ialah contoh hujung ke hujung yang menunjukkan skrip yang boleh digunakan untuk pelancaran, ujian yang menjalankannya dan panggilan kcov yang mengukur liputan. Perhatikan bahawa direktori output adalah khusus bagi setiap ujian supaya anda boleh menggabungkan hasil daripada beberapa pelaksanaan ujian kemudian.

#!/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"

Menggabungkan Liputan daripada Berbilang Pelaksanaan Ujian

Satu ujian jarang meliputi semua cabang. Anda menjalankan berbilang ujian — setiap satunya dalam direktori output liputan sendiri — kemudian menggabungkannya. Bendera --merge kcov menggabungkan beberapa pelaksanaan menjadi satu laporan bersatu.

Corak lazim dalam saluran paip CI:

  • Jalankan ujian A → output ke cov/test_a/
  • Jalankan ujian B → output ke cov/test_b/
  • Gabungkan → kcov --merge cov/all/ cov/test_a/ cov/test_b/
  • Huraikan cov/all/<script>/coverage.json untuk mendapatkan peratusan akhir

Anda juga boleh menguatkuasakan ambang minimum dan menggagalkan binaan CI jika liputan jatuh di bawahnya:

#!/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"

Liputan Cabang berbanding Liputan Baris

Terdapat dua metrik liputan utama yang akan anda temui:

  • Liputan baris — adakah baris ini dilaksanakan langsung? Mudah dimanipulasi: satu ujian boleh menyentuh banyak baris sambil terlepas laluan bersyarat yang penting.
  • Liputan cabang — adakah setiap cabang bagi setiap if, case dan &&/|| diambil? Isyarat yang jauh lebih kukuh. Memerlukan ujian bagi sisi benar dan palsu untuk setiap keputusan.

kcov melaporkan kedua-duanya. Kesimpulan penting: liputan baris 100% tidak bermaksud liputan cabang 100%. Pertimbangkan skrip ini — satu ujian dengan fail yang tidak kosong akan meliputi setiap baris, tetapi cabang fail kosong (baris 9 di bawah) tidak pernah dicapai:

#!/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")

Mengintegrasikan Fixture dan Liputan dalam CI

Menggabungkan semuanya: saluran paip CI yang kukuh untuk projek Bash menggabungkan persediaan fixture, pelaksanaan ujian menggunakan kcov, penggabungan, dan pemeriksaan ambang dalam satu skrip. Skrip ini menjadi titik masuk CI — satu perintah untuk menjalankan semuanya.

Prinsip reka bentuk untuk pelancar ujian CI:

  • Setiap kes ujian memanggil setup_fixture dan mendaftarkan teardown_fixture melalui trap
  • Skrip yang diuji dipanggil dengan $PATH palsu dan pemboleh ubah persekitaran berskop
  • kcov membungkus setiap panggilan dan menulis hasilnya ke subdirektori bernombor
  • Selepas semua ujian selesai, kcov menggabungkan hasil dan skrip ambang menentukan sama ada binaan boleh diteruskan
  • Pelancar CI keluar dengan kod bukan sifar jika mana-mana ujian atau pemeriksaan liputan gagal
#!/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 ))

Semakan Pengetahuan: Teknik PATH Palsu

Uji pemahaman anda tentang teknik PATH palsu yang digunakan dalam fixture ujian Bash.

Ulang Kaji: Fixture, Persekitaran Sementara dan Liputan

Pelajaran ini merangkumi keseluruhan himpunan alat untuk pengujian Bash yang boleh dipercayai dan terasing:

  • Direktori sementara — mktemp -d bersama trap ... EXIT menjamin pembersihan automatik tanpa mengira cara ujian berakhir.
  • Struktur fixture — pasangan setup_fixture / teardown_fixture mengisi dan memusnahkan pepohon direktori minimum yang mencerminkan input skrip sebenar.
  • PATH palsu — letakkan boleh laku tiruan dalam $FIXTURE/bin/ dan letakkannya di hadapan $PATH untuk memintas panggilan kepada curl, aws, docker atau mana-mana alat luaran tanpa menyentuh binari sistem.
  • Penskopan persekitaran — jalankan skrip yang diuji dalam subshell (() atau env -i) supaya pemboleh ubah yang diubah tidak bocor kembali kepada pelancar ujian.
  • Pengesahan — fungsi pembantu kecil (assert_eq, assert_file_exists, assert_contains) menghasilkan output lulus/gagal yang jelas serta mesej ralat yang bermakna.
  • Liputan kcov — membungkus pelaksanaan skrip tanpa perubahan pada kod sumber; menghasilkan laporan HTML dan JSON untuk liputan baris dan cabang.
  • Penggabungan dan ambang — gabungkan berbilang pelaksanaan kcov dengan --merge, huraikan JSON dan gagalkan CI jika liputan jatuh di bawah nilai minimum anda.
  • Liputan cabang berbanding liputan baris — sentiasa sasarkan liputan cabang; liputan baris sahaja mungkin terlepas keseluruhan laluan bersyarat dan memberikan keyakinan palsu.

Dengan teknik ini, ujian Bash anda menjadi sama teliti seperti ujian untuk mana-mana bahasa terkompil.

Percuma untuk bermula

Pelajari Bash dengan tutor kecerdasan buatan — percuma

Tulis dan jalankan kod sebenar dalam pelayar anda, dapatkan bantuan segera daripada tutor kecerdasan buatan yang tersedia 24/7, dan sambung semula dari tempat anda berhenti di web atau dalam aplikasi.

Kursus
22
Pelajaran
88

Soalan Lazim

Adakah pelajaran “Lekapan Ujian, Persekitaran Sementara dan Liputan” percuma?

Ya — teks penuh “Lekapan Ujian, Persekitaran Sementara dan Liputan” boleh dibaca secara percuma di web ini. Untuk berlatih secara interaktif menggunakan penyunting kod terbina dalam dan tutor kecerdasan buatan 24/7, serta membuka kunci baki kursus Penguasaan Baris Perintah Linux &amp; Penskripan Bash, tingkat taraf kepada CoddyKit PRO. Kursus Penguasaan Baris Perintah Linux &amp; Penskripan Bash merangkumi sejumlah 4 pelajaran.

Apakah yang akan saya pelajari dalam “Lekapan Ujian, Persekitaran Sementara dan Liputan”?

Bina lekapan ujian terpencil dan ukur cabang skrip yang benar-benar dilalui oleh ujian anda Anda berlatih Penguasaan Baris Perintah Linux &amp; Penskripan Bash menggunakan kod praktikal yang dijalankan terus dalam pelayar, manakala tutor kecerdasan buatan 24/7 menjawab soalan anda semasa anda mengikuti pelajaran.

Adakah saya memerlukan pengalaman untuk memulakan Penguasaan Baris Perintah Linux &amp; Penskripan Bash?

Tiada pengalaman terdahulu diperlukan. Pembelajaran Penguasaan Baris Perintah Linux &amp; Penskripan Bash di CoddyKit disusun untuk pelajar daripada peringkat pemula hingga lanjutan, jadi anda boleh bermula di sini atau dari awal dan belajar mengikut kadar anda sendiri. Ini ialah pelajaran 3 daripada 4.

Berapa lamakah pelajaran “Lekapan Ujian, Persekitaran Sementara dan Liputan” diambil?

Kebanyakan pelajaran CoddyKit mengambil masa kira-kira 5–10 minit. Setiap pelajaran ringkas dan interaktif, jadi anda boleh membuat kemajuan secara berterusan dan menyambung tepat dari tempat anda berhenti di web atau aplikasi.

Bolehkah saya menulis dan menjalankan kod dalam pelajaran Penguasaan Baris Perintah Linux &amp; Penskripan Bash ini?

Ya. Setiap pelajaran Penguasaan Baris Perintah Linux &amp; Penskripan Bash menyertakan penyunting kod terbina dalam, jadi anda boleh menulis dan menjalankan kod sebenar terus dalam pelayar serta menerima maklum balas kecerdasan buatan serta-merta — tanpa memerlukan persediaan setempat.

Semua pelajaran dalam kursus ini

  1. Pengujian Unit Fungsi dengan Bats-core
  2. Meniru Perintah dan Menyediakan Alat Luaran Palsu
  3. Lekapan Ujian, Persekitaran Sementara dan Liputan
  4. Menjalankan Ujian Shell dalam Saluran Paip CI
← Kembali ke Penguasaan Baris Perintah Linux &amp; Penskripan Bash