بيانات الاختبار والبيئات المؤقتة وتغطية الاختبارات
أنشئ بيانات اختبار معزولة وقِس فروع السكربت التي تغطيها اختباراتك فعليًا
بيانات الاختبار والبيئات المؤقتة وتغطية الاختبارات درس مجاني في 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. لا تريدون في الاختبارات الوصول إلى الخدمات الحقيقية، لذا تستبدلون تلك الأدوات بملفات تنفيذية وهمية.
التقنية بسيطة:
- أنشئوا دليل
bin/مؤقتًا داخل ملف الاختبار - اكتبوا فيه برامج shell نصية صغيرة بأسماء الأدوات الحقيقية نفسها
- أضيفوا ذلك الدليل إلى بداية
$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 يتضمن محرر أكواد مدمج، لذا تكتب وتشغل أكواداً حقيقية مباشرة في متصفحك وتحصل على تعليقات فورية من الذكاء الاصطناعي — بدون إعداد محلي.
جميع الدروس في هذه الدورة
- اختبار الدوال بوحدة باستخدام Bats-core
- محاكاة الأوامر وإنشاء بدائل للأدوات الخارجية
- بيانات الاختبار والبيئات المؤقتة وتغطية الاختبارات
- تشغيل اختبارات Shell في مسارات CI