تطبيق: إعادة تنظيم مع اختبار

Refactor with Tests

تطبيق ~22 دقيقة

تطبيق: إعادة تنظيم مع اختبار — Refactor with Tests

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

سنأخذ منطق تصنيف HTTP status ونضعه في دالة classify_status. بعدها نختبر 200 و503. لو فشلت الدالة، يعرف الاختبار فوراً. لاحقاً يمكن استخدام الدالة مع curl بدون خلط الشبكة بالمنطق.

مثال: فشل الاختبار مرئي

قبل أن نرى النموذج الصحيح، انظر ما يحدث عندما تفشل دالة غير صحيحة:

classify_status() {
    echo "ok"   # دالة خاطئة: تُرجع "ok" دائماً
}
assert_eq() {
    [[ "$1" == "$2" ]] || { echo "FAIL: expected '$1' got '$2'" >&2; return 1; }
}
assert_eq "bad" "$(classify_status 503)"   # يُطبع: FAIL: expected 'bad' got 'ok'

assert_eq يُنتج رسالة فشل واضحة مع القيم المتوقعة والفعلية. هذا هو المطلوب: الاختبار يجب أن يُخبرك بدقة ما الخطأ.

نموذج منظم

script.sh

#!/usr/bin/env bash
set -euo pipefail

classify_status() {
	local status="$1"
	case "$status" in
		2*) echo "ok" ;;
		*) echo "bad" ;;
	esac
}

assert_eq() {
	[[ "$1" == "$2" ]] || {
		echo "expected $1 got $2" >&2
		return 1
	}
}

assert_eq "ok" "$(classify_status 200)"
assert_eq "bad" "$(classify_status 503)"
echo "refactor safe"

Output:

لاحظ أن الدالة لا تعرف شيئاً عن curl. هذا مقصود. كلما فصلت الأجزاء، صار الاختبار أسهل.

ماذا بعد؟

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

تحدي — Challenge

#!/usr/bin/env bash
set -euo pipefail

classify_number() {
	# صنف الرقم — Classify the number
}

classify_number 7