0Pricing
Linux Command Line & Bash Scripting Mastery · درس

بيانات الاختبار والبيئات المؤقتة وتغطية الاختبارات

أنشئ بيانات اختبار معزولة وقِس فروع السكربت التي تغطيها اختباراتك فعليًا

بيانات الاختبار والبيئات المؤقتة وتغطية الاختبارات درس مجاني في Linux Command Line & Bash Scripting Mastery على CoddyKit. هذا هو الدرس 3 من أصل 4. يمكنك قراءة الدرس كاملاً أدناه مجاناً — ثم تمرن عليه مباشرة في المتصفح باستخدام محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7. هذا الدرس جزء من مسار التعلم في Linux Command Line & Bash Scripting Mastery، وتقدمك يتزامن عبر الويب وتطبيق CoddyKit. تتضمن دورة Linux Command Line & Bash Scripting Mastery 4 دروس في المجموع.

أهمية ملفات الاختبار والعزل

عند اختبار البرامج النصية في Bash، يتمثل أكبر خطر في الآثار الجانبية: فقد تعدّل اختباراتكم ملفات حقيقية أو قواعد بيانات حقيقية أو حالة النظام الحقيقية عن طريق الخطأ. والاختبار الذي ينجح على جهازكم لكنه يتسبب في إفساد بيانات الإنتاج أسوأ من عدم وجود اختبار على الإطلاق.

الحل هو ملفات الاختبار، وهي بيئات مضبوطة وقابلة للتخلص منها تحاكي الظروف الحقيقية من دون لمس أي شيء حقيقي. وتوفر ملفات الاختبار الجيدة ما يلي:

  • قابلية إعادة الإنتاج — تنتج الاختبارات النتيجة نفسها في كل تشغيل
  • العزل — لا تتداخل الاختبارات مع بعضها أو مع المضيف
  • الأمان — لا تلمس العمليات التدميرية إلا بيانات قابلة للتخلص منها
  • السرعة — لا توجد استدعاءات شبكة أو عمليات إدخال وإخراج مكثفة إلا عند الضرورة القصوى

في اختبار Bash، تكون ملفات الاختبار عادةً أدلة مؤقتة مملوءة بملفات معروفة، وملفات تنفيذية وهمية موضوعة في بداية $PATH، ومتغيرات بيئة محصورة في عملية الاختبار.

إنشاء الأدلة المؤقتة وتنظيفها

يستخدم النمط القياسي لإنشاء دليل مؤقت خاص بكل اختبار الأمر mktemp -d، الذي ينشئ دليلًا فريدًا في /tmp ويطبع مساره. خزّنوا المسار وسجّلوا trap لإزالته تلقائيًا عند خروج shell، حتى في حالة الفشل.

ينبغي أن يظهر هذا الأسلوب المختصر المؤلف من سطرين في كل ملف اختبار يتعامل مع نظام الملفات:

#!/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. اكتبوا فيه برامج shell نصية صغيرة بأسماء الأدوات الحقيقية نفسها
  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"

التقاط مخرجات الأوامر والتحقق منها

لا يكون ملف الاختبار مفيدًا إلا إذا استطعتم التحقق مما فعله البرنامج النصي. الأنماط القياسية هي:

  • التقاط stdout/stderr في متغيرات باستخدام $() أو استبدال العمليات
  • فحص ملفات السجل التي تكتبها الملفات التنفيذية الوهمية
  • التحقق من رموز الخروج صراحةً باستخدام $? أو المنطق الشرطي
  • التحقق من إنشاء ملفات معينة أو تعديلها أو عدم المساس بها

يساعدكم إنشاء دوال صغيرة ومركزة للتحقق في جعل اختباراتكم سهلة القراءة، ويوفر لكم رسائل فشل دقيقة عند حدوث خطأ ما.

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

مقدمة إلى kcov لتغطية Bash

تجيب التغطية عن السؤال التالي: ما الأسطر (والفروع) في البرنامج النصي التي نفذتها الاختبارات فعليًا؟ لا يضمن ارتفاع نسبة التغطية صحة البرنامج، لكن انخفاضها يكشف المسارات غير المختبرة التي يُرجح أن تحتوي على أخطاء.

الأداة الأساسية لتغطية Bash هي kcov. فهي تعمل عبر إدخال أدوات القياس في البرنامج النصي على مستوى نظام التشغيل باستخدام PTRACE (في Linux) أو dtrace (في macOS)، ولذلك لا تتطلب أي تغييرات في الشيفرة المصدرية. وتنتج تقرير HTML يعرض الأسطر الحمراء (غير المغطاة) والخضراء (المغطاة).

الاستخدام الأساسي:

  • kcov --include-path=./src coverage-out/ ./src/myscript.sh
  • افتحوا coverage-out/index.html في متصفح لفحص النتائج
  • في CI، حلّلوا coverage-out/myscript.sh/coverage.json للحصول على نسبة قابلة للقراءة آليًا

ملاحظة: يجب تثبيت kcov separately (brew install kcov في macOS، وapt install kcov في Ubuntu 20.04 فأحدث).

تشغيل 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"

دمج التغطية من عمليات اختبار متعددة

نادرًا ما يغطي اختبار واحد جميع الفروع. تشغّلون اختبارات متعددة، كل منها في دليل مخرجات تغطية خاص به، ثم تدمجونها. يجمع الخيار --merge في kcov عمليات التشغيل المتعددة في تقرير موحّد واحد.

النمط المعتاد في خط أنابيب 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")

دمج الـ Fixtures وتغطية الاختبارات في CI

جمع كل ذلك معًا: يدمج خط أنابيب CI متين لمشروعات Bash إعداد الـ fixtures، وتنفيذ الاختبارات باستخدام kcov، والدمج، والتحقق من الحد الأدنى في نص برمجي واحد. ويصبح هذا النص البرمجي نقطة الدخول إلى CI — أمرًا واحدًا لتشغيل كل شيء.

مبادئ تصميم مشغّل اختبارات CI:

  • يستدعي كل اختبار setup_fixture ويسجّل teardown_fixture عبر trap
  • يُستدعى النص البرمجي قيد الاختبار باستخدام $PATH وهمي ومتغيرات بيئية محددة النطاق
  • يغلّف kcov كل استدعاء، ويكتب النتائج في مجلد فرعي مُرقّم
  • بعد اكتمال جميع الاختبارات، يدمج kcov النتائج ويتحقق نص الحد الأدنى من استيفاء البناء للشرط
  • يُخرج مشغّل CI قيمة غير صفرية إذا فشل أي اختبار أو فشل فحص التغطية
#!/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 الوهمي

اختبر مدى فهمك لتقنية PATH الوهمي المستخدمة في fixtures الخاصة باختبارات Bash.

مراجعة: Fixtures والبيئات المؤقتة وتغطية الاختبارات

تناول هذا الدرس مجموعة الأدوات الكاملة لإجراء اختبارات Bash موثوقة ومعزولة:

  • المجلدات المؤقتة — يضمن استخدام mktemp -d مع trap ... EXIT التنظيف التلقائي بغض النظر عن طريقة انتهاء الاختبار.
  • بنية الـ Fixture — ينشئ زوج setup_fixture / teardown_fixture شجرة مجلدات مصغّرة، ثم يتخلص منها، بحيث تحاكي مدخلات النصوص البرمجية الفعلية.
  • PATH الوهمي — ضع الملفات التنفيذية البديلة في $FIXTURE/bin/ وأضفها في بداية $PATH لاعتراض الاستدعاءات إلى curl أو aws أو docker أو أي أداة خارجية من دون المساس بالملفات التنفيذية للنظام.
  • تحديد نطاق البيئة — شغّل النص البرمجي قيد الاختبار في subshell ‏(() أو env -i) حتى لا تتسرّب المتغيرات التي تغيّرت إلى مشغّل الاختبار.
  • التأكيدات — تنتج الدوال المساعدة الصغيرة (assert_eq وassert_file_exists وassert_contains) مخرجات واضحة للنجاح أو الفشل ورسائل خطأ مفيدة.
  • تغطية kcov — يغلّف تنفيذ النص البرمجي من دون إجراء تغييرات على المصدر، وينتج تقارير HTML وJSON لتغطية الأسطر والفروع.
  • الدمج والحد الأدنى — ادمج عمليات تشغيل kcov المتعددة باستخدام --merge، وحلّل JSON، وافشل CI إذا انخفضت التغطية عن الحد الأدنى.
  • تغطية الفروع مقابل تغطية الأسطر — استهدف دائمًا تغطية الفروع؛ فتغطية الأسطر وحدها قد تفوّت مسارات شرطية كاملة وتعطي ثقة زائفة.

باستخدام هذه التقنيات، تصبح اختبارات Bash صارمة بقدر اختبارات أي لغة مترجمة.

الأسئلة الشائعة

هل درس «بيانات الاختبار والبيئات المؤقتة وتغطية الاختبارات» مجاني؟

نعم — نص درس «بيانات الاختبار والبيئات المؤقتة وتغطية الاختبارات» كامل متاح مجاناً هنا على الويب. لتمرينه بشكل تفاعلي (محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7) وفتح باقي دورة Linux Command Line & Bash Scripting Mastery، انتقل إلى CoddyKit PRO. تتضمن دورة Linux Command Line & Bash Scripting Mastery 4 دروس في المجموع.

ماذا ستتعلم في «بيانات الاختبار والبيئات المؤقتة وتغطية الاختبارات»؟

أنشئ بيانات اختبار معزولة وقِس فروع السكربت التي تغطيها اختباراتك فعليًا تتمرن على Linux Command Line & Bash Scripting Mastery مع أكواد عملية تشغلها مباشرة في المتصفح، ومدرس ذكاء اصطناعي متاح 24/7 يجيب على أسئلتك أثناء عملك.

هل أحتاج إلى خبرة سابقة لأبدأ Linux Command Line & Bash Scripting Mastery؟

لا تُشترط خبرة سابقة. Linux Command Line & Bash Scripting Mastery على CoddyKit منظم للمبتدئين حتى المتقدمين، لذا يمكنك البدء من هنا أو من البداية والتقدم بسرعتك الخاصة. هذا هو الدرس 3 من أصل 4.

كم من الوقت يستغرق درس «بيانات الاختبار والبيئات المؤقتة وتغطية الاختبارات»؟

معظم دروس CoddyKit تستغرق حوالي 5–10 دقائق. كل منها موجز وتفاعلي، لذا تحرز تقدماً مستمراً وتستأنف من حيث توقفت عبر الويب والتطبيق.

هل يمكنني كتابة وتشغيل أكواد في درس Linux Command Line & Bash Scripting Mastery هذا؟

نعم. كل درس في Linux Command Line & Bash Scripting Mastery يتضمن محرر أكواد مدمج، لذا تكتب وتشغل أكواداً حقيقية مباشرة في متصفحك وتحصل على تعليقات فورية من الذكاء الاصطناعي — بدون إعداد محلي.

جميع الدروس في هذه الدورة

  1. اختبار الدوال بوحدة باستخدام Bats-core
  2. محاكاة الأوامر وإنشاء بدائل للأدوات الخارجية
  3. بيانات الاختبار والبيئات المؤقتة وتغطية الاختبارات
  4. تشغيل اختبارات Shell في مسارات CI
← العودة إلى Linux Command Line & Bash Scripting Mastery