फ़िक्स्चर, अस्थायी परिवेश और कवरेज
पृथक जाँच फ़िक्स्चर बनाएँ और मापें कि आपकी जाँच वास्तव में स्क्रिप्ट की किन शाखाओं को चलाती है।
फ़िक्स्चर, अस्थायी परिवेश और कवरेज, CoddyKit पर Linux कमांड लाइन और Bash स्क्रिप्टिंग में महारत का एक निःशुल्क पाठ है। यह 4 में से 3वाँ पाठ है। आप नीचे पूरा पाठ निःशुल्क पढ़ सकते हैं—फिर अंतर्निहित कोड संपादक और 24/7 एआई ट्यूटर के साथ ब्राउज़र में इसका व्यावहारिक अभ्यास कर सकते हैं। यह Linux कमांड लाइन और Bash स्क्रिप्टिंग में महारत सीखने के मार्ग का हिस्सा है और आपकी प्रगति वेब तथा CoddyKit ऐप पर सिंक होती रहती है। Linux कमांड लाइन और Bash स्क्रिप्टिंग में महारत पाठ्यक्रम में कुल 4 पाठ शामिल हैं।
फ़िक्स्चर और पृथक्करण क्यों महत्वपूर्ण हैं
Bash स्क्रिप्ट का परीक्षण करते समय सबसे बड़ा जोखिम दुष्प्रभाव होता है: आपके परीक्षण गलती से वास्तविक फ़ाइलों, वास्तविक डेटाबेस या वास्तविक सिस्टम स्थिति में बदलाव कर सकते हैं। आपकी मशीन पर सफल होने वाला, लेकिन उत्पादन डेटा को दूषित करने वाला परीक्षण, किसी परीक्षण के न होने से भी बदतर है।
समाधान है परीक्षण फ़िक्स्चर — नियंत्रित, नष्ट किए जा सकने वाले वातावरण, जो वास्तविक परिस्थितियों की नकल करते हैं लेकिन वास्तविक चीज़ों को नहीं छूते। अच्छे फ़िक्स्चर आपको ये सुविधाएँ देते हैं:
- पुनरुत्पादकता — हर बार परीक्षण समान परिणाम देते हैं
- पृथक्करण — परीक्षण एक-दूसरे या होस्ट में हस्तक्षेप नहीं करते
- सुरक्षा — विनाशकारी कार्रवाइयाँ केवल फेंके जा सकने वाले डेटा पर होती हैं
- गति — नेटवर्क कॉल नहीं होतीं और जब तक बिल्कुल आवश्यक न हो, भारी इनपुट-आउटपुट भी नहीं होता
Bash परीक्षण में फ़िक्स्चर आम तौर पर ज्ञात फ़ाइलों से भरी अस्थायी डायरेक्टरी, $PATH में आरंभ में रखे गए नकली निष्पादन योग्य प्रोग्राम और परीक्षण प्रक्रिया तक सीमित वातावरण चर होते हैं।
अस्थायी डायरेक्टरी बनाना और साफ़ करना
प्रत्येक परीक्षण के लिए अस्थायी डायरेक्टरी बनाने का मानक पैटर्न mktemp -d का उपयोग करता है। यह /tmp में एक अनोखी डायरेक्टरी बनाता है और उसका पथ प्रिंट करता है। आप उस पथ को संग्रहित करते हैं और शेल से बाहर निकलने पर — विफलता की स्थिति में भी — उसे स्वतः हटाने के लिए trap पंजीकृत करते हैं।
फ़ाइल सिस्टम को छूने वाली हर परीक्षण फ़ाइल में यह दो-पंक्ति तरीका होना चाहिए:
#!/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/डायरेक्टरी बनाएँ - वहाँ वास्तविक टूल के समान नाम वाली छोटी शेल स्क्रिप्ट लिखें
- अपनी परीक्षणाधीन स्क्रिप्ट को कॉल करने से पहले उस डायरेक्टरी को
$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"Bash कवरेज के लिए kcov का परिचय
कवरेज इस प्रश्न का उत्तर देता है: मेरी स्क्रिप्ट की कौन-सी पंक्तियाँ (और शाखाएँ) परीक्षणों ने वास्तव में चलाईं? अधिक कवरेज प्रतिशत सही होने की गारंटी नहीं देता, लेकिन कम कवरेज उन अपरीक्षित मार्गों को उजागर करता है जिनमें बग होने की संभावना रहती है।
Bash कवरेज का मुख्य टूल kcov है। यह PTRACE (Linux) या dtrace (macOS) का उपयोग करके OS स्तर पर स्क्रिप्ट में उपकरण जोड़कर काम करता है, इसलिए आपके स्रोत कोड में बदलाव की आवश्यकता नहीं होती। यह लाल (अपरीक्षित) और हरी (परीक्षित) पंक्तियाँ दिखाने वाली HTML रिपोर्ट बनाता है।
मूल उपयोग:
kcov --include-path=./src coverage-out/ ./src/myscript.sh- परिणाम देखने के लिए ब्राउज़र में
coverage-out/index.htmlखोलें - CI में मशीन-पठनीय प्रतिशत के लिए
coverage-out/myscript.sh/coverage.jsonको पार्स करें
ध्यान दें: kcov को अलग से इंस्टॉल करना आवश्यक है (macOS पर brew install kcov, Ubuntu 20.04+ पर apt install kcov)।
वास्तविक स्क्रिप्ट पर 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"कई परीक्षण-चक्रों से कवरेज मिलाना
एक अकेला परीक्षण शायद ही सभी शाखाओं को कवर करता है। आप कई परीक्षण चलाते हैं — प्रत्येक को अपनी कवरेज आउटपुट डायरेक्टरी में — और फिर उन्हें मिलाते हैं। kcov का --merge फ़्लैग कई चक्रों को एकीकृत रिपोर्ट में जोड़ता है।
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")CI में फ़िक्स्चर और कवरेज का एकीकरण
सब कुछ एक साथ जोड़ने पर Bash प्रोजेक्ट के लिए एक मज़बूत CI पाइपलाइन एक ही स्क्रिप्ट में फ़िक्स्चर सेटअप, kcov के अंतर्गत परीक्षण चलाना, मर्ज करना और न्यूनतम सीमा की जाँच करना जोड़ती है। यह स्क्रिप्ट CI का प्रवेश-बिंदु बन जाती है — सब कुछ चलाने के लिए केवल एक कमांड।
CI परीक्षण रनर के लिए डिज़ाइन सिद्धांत:
- हर परीक्षण मामला
setup_fixtureको कॉल करता है औरtrapके माध्यम सेteardown_fixtureपंजीकृत करता है - परीक्षणाधीन स्क्रिप्ट को नकली
$PATHऔर सीमित दायरे वाले env vars के साथ चलाया जाता है - 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 तकनीक
Bash परीक्षण फ़िक्स्चर में इस्तेमाल की गई नकली PATH तकनीक की अपनी समझ जाँचिए।
पुनरावलोकन: फ़िक्स्चर, अस्थायी परिवेश और कवरेज
इस पाठ में भरोसेमंद और पृथक Bash परीक्षण के लिए पूरा टूलकिट शामिल किया गया:
- अस्थायी निर्देशिकाएँ —
mktemp -dऔरtrap ... EXITका संयोजन इस बात की गारंटी देता है कि परीक्षण किसी भी तरह समाप्त हो, सफ़ाई अपने-आप हो जाएगी। - फ़िक्स्चर संरचना —
setup_fixture/teardown_fixtureकी जोड़ी एक ऐसी न्यूनतम निर्देशिका संरचना बनाती और हटाती है, जो वास्तविक स्क्रिप्ट इनपुट की नकल करती है। - नकली PATH —
$FIXTURE/bin/में स्टब निष्पादनयोग्य फ़ाइलें रखें और उसे$PATHके आगे जोड़ें, ताकि सिस्टम बाइनरी को छुए बिनाcurl,aws,dockerया किसी भी बाहरी टूल के कॉल को बीच में पकड़ा जा सके। - परिवेश का दायरा — परीक्षणाधीन स्क्रिप्ट को सबशेल (
()याenv -i) में चलाएँ, ताकि बदले हुए वैरिएबल परीक्षण रनर में वापस न पहुँचें। - अभिकथन — छोटे सहायक फ़ंक्शन (
assert_eq,assert_file_exists,assert_contains) स्पष्ट सफल/विफल आउटपुट और अर्थपूर्ण त्रुटि संदेश देते हैं। - kcov कवरेज — स्रोत में बदलाव किए बिना स्क्रिप्ट के निष्पादन को रैप करता है और पंक्ति तथा शाखा कवरेज के लिए HTML और JSON रिपोर्ट बनाता है।
- मर्ज और न्यूनतम सीमा —
--mergeके साथ कई kcov रन को मिलाएँ, JSON को पार्स करें और कवरेज आपकी न्यूनतम सीमा से नीचे जाने पर CI को विफल करें। - शाखा बनाम पंक्ति कवरेज — हमेशा शाखा कवरेज को लक्ष्य बनाएँ; केवल पंक्ति कवरेज से पूरी सशर्त राहें छूट सकती हैं और झूठा भरोसा पैदा हो सकता है।
इन तकनीकों से आपके Bash परीक्षण किसी भी कंपाइल की जाने वाली भाषा के परीक्षणों जितने कठोर बन जाते हैं।
एआई शिक्षक के साथ Bash सीखें — निःशुल्क
अपने ब्राउज़र में वास्तविक कोड लिखें और चलाएँ, चौबीसों घंटे एआई शिक्षक से तुरंत सहायता पाएँ, और वेब या ऐप पर वहीं से शुरू करें जहाँ आपने छोड़ा था।
- पाठ्यक्रम
- 22
- पाठ
- 88
अक्सर पूछे जाने वाले प्रश्न
क्या “फ़िक्स्चर, अस्थायी परिवेश और कवरेज” पाठ निःशुल्क है?
हाँ—“फ़िक्स्चर, अस्थायी परिवेश और कवरेज” का पूरा पाठ यहाँ वेब पर निःशुल्क पढ़ा जा सकता है। इंटरैक्टिव अभ्यास (अंतर्निहित कोड संपादक और 24/7 एआई ट्यूटर) करने और Linux कमांड लाइन और Bash स्क्रिप्टिंग में महारत पाठ्यक्रम का बाकी हिस्सा अनलॉक करने के लिए CoddyKit PRO लें। Linux कमांड लाइन और Bash स्क्रिप्टिंग में महारत पाठ्यक्रम में कुल 4 पाठ शामिल हैं।
“फ़िक्स्चर, अस्थायी परिवेश और कवरेज” में मैं क्या सीखूँगा?
पृथक जाँच फ़िक्स्चर बनाएँ और मापें कि आपकी जाँच वास्तव में स्क्रिप्ट की किन शाखाओं को चलाती है। आप ब्राउज़र में सीधे चलाए जाने वाले व्यावहारिक कोड के साथ Linux कमांड लाइन और Bash स्क्रिप्टिंग में महारत का अभ्यास करते हैं, और पाठ पूरा करते समय 24/7 एआई ट्यूटर आपके प्रश्नों के उत्तर देता है।
क्या Linux कमांड लाइन और Bash स्क्रिप्टिंग में महारत शुरू करने के लिए मुझे किसी अनुभव की आवश्यकता है?
पहले के अनुभव की आवश्यकता नहीं है। CoddyKit पर Linux कमांड लाइन और Bash स्क्रिप्टिंग में महारत शुरुआती से लेकर उन्नत शिक्षार्थियों तक सभी के लिए व्यवस्थित किया गया है, इसलिए आप यहीं से या शुरुआत से सीखना शुरू कर सकते हैं और अपनी गति से आगे बढ़ सकते हैं। यह 4 में से 3वाँ पाठ है।
“फ़िक्स्चर, अस्थायी परिवेश और कवरेज” पाठ पूरा करने में कितना समय लगता है?
CoddyKit का अधिकांश पाठ लगभग 5–10 मिनट में पूरा हो जाता है। हर पाठ छोटा और संवादात्मक है, इसलिए आप लगातार प्रगति करते हैं और वेब या ऐप पर वहीं से सीखना जारी रख सकते हैं जहाँ आपने छोड़ा था।
क्या मैं इस Linux कमांड लाइन और Bash स्क्रिप्टिंग में महारत पाठ में कोड लिख और चला सकता हूँ?
हाँ। हर Linux कमांड लाइन और Bash स्क्रिप्टिंग में महारत पाठ में एक अंतर्निर्मित कोड संपादक शामिल है, जिससे आप सीधे अपने ब्राउज़र में वास्तविक कोड लिख और चला सकते हैं और तुरंत एआई प्रतिक्रिया पा सकते हैं—स्थानीय सेटअप की आवश्यकता नहीं है।
इस पाठ्यक्रम के सभी पाठ
- Bats-core से फ़ंक्शन की यूनिट जाँच
- कमांड का मॉक बनाना और बाहरी टूल के स्टब तैयार करना
- फ़िक्स्चर, अस्थायी परिवेश और कवरेज
- CI पाइपलाइनों में Shell जाँच चलाना