TDD: لماذا يهرب منه المطورون رغم أنه ينقذ المشاريع؟ الحقيقة والحل الوسط الذي لا يتحدث عنه أحد

تخيل أنك تعمل على مشروع ضخم منذ ثلاثة أشهر، وكلما أضفت ميزة جديدة، تظهر ثلاث بَجَّات في أماكن لم تمسها منذ أسابيع. أنت تعرف أن TDD كان يمكن أن يمنع هذا، لكنك لم تطبقه لأنك ببساطة لا تملك الوقت. هذه ليست مأساة شخصية، بل واقع يومي في ٨٠٪ من فرق البرمجة حسب استطلاع Stack Overflow الأخير. المشكلة ليست في أن TDD لا يعمل، بل في أن تطبيقه بحذافيره يشبه محاولة بناء ناطحة سحاب باستخدام أدوات نجارة يدوية.

الحقيقة المؤلمة هي أن TDD ليس مجرد أسلوب كتابة كود، بل ثقافة كاملة تتطلب تغييراً جذرياً في طريقة التفكير والعمل. معظم المطورين يتركونه ليس لأنهم كسالى، بل لأنهم يصطدمون بحائط من المشاكل العملية التي لا تغطيها الكتب والدورات: ضغط المواعيد النهائية، كود ليغاسي معقد، فرق غير متجانسة الخبرة، ومديرين لا يفهمون لماذا يستغرق الأمر ضعف الوقت لكتابة نفس الميزة. لكن هذا لا يعني أن نلقي بTDD في القمامة. الحل يكمن في إيجاد توازن عملي بين فوائده ومتطلبات الواقع.

لماذا TDD يبدو وكأنه لعنة وليست نعمة؟

عندما تتحدث مع مطورين جربوا TDD ثم تركوه، ستسمع نفس الشكاوى تقريباً: "الأكواد أصبحت أطول بمرتين"، "نحن نكتب اختبارات لشيء لم يوجد بعد!"، "العميل يريد الميزة اليوم وليس غداً". هذه ليست مبررات واهية، بل أعراض لمشاكل حقيقية في تطبيق TDD بشكل أعمى. لنفترض أنك تعمل على نظام دفع إلكتروني، والمتطلب هو إضافة طريقة دفع جديدة عبر باي بال. في سيناريو TDD التقليدي، ستكتب أولاً اختباراً يفشل لأن الدالة التي ستتعامل مع باي بال غير موجودة بعد. هذا يبدو منطقياً نظرياً، لكن عملياً ستجد نفسك تكافح مع أسئلة لا نهاية لها: ما هي حدود الدالة؟ كيف ستتعامل مع الأخطاء؟ هل يجب أن تتعامل مع الـwebhook من باي بال الآن أم لاحقاً؟

المشكلة الأكبر هي أن TDD يفترض أن لديك فهماً كاملاً للمتطلبات قبل البدء بالكتابة، وهذا نادراً ما يحدث في الواقع. معظم المشاريع تبدأ بمتطلبات غامضة تتطور مع الوقت، وغالباً ما تتغير بعد كتابة الاختبارات. تخيل أنك كتبت ٥٠ اختباراً لواجهة برمجة تطبيقات لمعالجة الطلبات، ثم يأتي العميل ويقول: "نريد إضافة خاصية الخصم التلقائي بناءً على سلوك المستخدم". فجأة، كل اختباراتك أصبحت قديمة ويجب إعادة كتابتها. هذا ليس فشلاً في TDD بحد ذاته، بل فشل في توقعاتنا حول كيفية عمله في بيئات ديناميكية.

التشريح التقني: ماذا يحدث خلف الكواليس عندما تطبق TDD؟

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

// test/taskManager.test.ts
import { TaskManager } from '../src/taskManager';

describe('TaskManager', () => {
 it('should add a new task', () => {
 const manager = new TaskManager();
 const task = { id: '1', title: 'Buy milk', completed: false };
 manager.addTask(task);
 expect(manager.getTasks()).toContainEqual(task);
 });
});

عندما تشغل هذا الاختبار، سيحدث ما يلي في الخلفية: أولاً، سيقوم الـtest runner (مثل Jest) بتحميل ملف الاختبار في الذاكرة. ثم سيبدأ في تنفيذ الكود سطراً بسطر. عندما يصل إلى سطر إنشاء TaskManager، سيحاول الـJavaScript engine إنشاء كائن جديد في الـheap memory. لكن بما أن الكود غير موجود بعد، سيظهر خطأ من نوع ReferenceError. هذا الخطأ ليس مجرد فشل في الاختبار، بل هو إشارة للمطور أن الكود الأساسي مفقود.

الآن، عندما تكتب الكود الفعلي لجعل الاختبار ينجح، سيحدث الآتي:

// src/taskManager.ts
export class TaskManager {
 private tasks: Array<{ id: string; title: string; completed: boolean }> = [];

 addTask(task: { id: string; title: string; completed: boolean }): void {
 this.tasks.push(task);
 }

 getTasks() {
 return this.tasks;
 }
}

عندما يعيد الـtest runner تشغيل الاختبار، سيقوم بإنشاء كائن TaskManager جديد في الذاكرة، وسيخصص مساحة في الـheap لتخزين مصفوفة المهام. ثم سيضيف المهمة الجديدة إلى هذه المصفوفة، وفي النهاية سيقارن محتويات المصفوفة مع المتوقع. هذه العملية تبدو بسيطة، لكنها تكشف عن نقطة مهمة: TDD يجبرك على التفكير في بنية البيانات والذاكرة قبل كتابة الكود الفعلي، وهذا ما يقلل من الـmemory leaks والـside effects لاحقاً.

لكن المشكلة تظهر عندما تتوسع الأمور. لنفترض أنك أضفت ميزة جديدة لحذف المهام، وكتبت الاختبار التالي:

it('should delete a task by id', () => {
 const manager = new TaskManager();
 manager.addTask({ id: '1', title: 'Buy milk', completed: false });
 manager.deleteTask('1');
 expect(manager.getTasks()).toHaveLength(0);
});

هنا، ستجد نفسك مضطراً لتعديل الكود الأصلي لإضافة دالة deleteTask. لكن ماذا لو كانت المهام مرتبطة بقاعدة بيانات؟ ماذا لو كان هناك EventEmitter ينبه أجزاء أخرى من النظام عند حذف مهمة؟ فجأة، اختبار بسيط يتحول إلى مشكلة معقدة تتطلب فهم الـevent loop والـasynchronous operations. هذا هو السبب الذي يجعل الكثير من المطورين يتركون TDD عندما تصل الأمور إلى مستوى معين من التعقيد.

الفخاخ الخفية التي تقع فيها الفرق عند تطبيق TDD

هناك عدة فخاخ تقنية تجعل من TDD كابوساً بدلاً من أداة مفيدة. الفخ الأول هو ما أسميه "الاختبارات الوهمية"، وهي اختبارات تمر ولكن لا تختبر شيئاً مفيداً. مثلاً، اختبار مثل هذا:

test('should return true when user is admin', () => {
 const isAdmin = (role) => role === 'admin';
 expect(isAdmin('admin')).toBe(true);
});

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

الفخ الثالث والأخطر هو "التداخل في الاختبارات". يحدث هذا عندما تعتمد اختبارات على حالة معينة أنشأها اختبار سابق. مثلاً:

# test_cart.py
import pytest
from cart import Cart

@pytest.fixture
def cart():
 return Cart()

def test_add_item(cart):
 cart.add_item("book", 10)
 assert cart.total == 10

def test_remove_item(cart):
 cart.add_item("book", 10)
 cart.remove_item("book")
 assert cart.total == 0

هنا، يعتمد اختبار remove_item على أن add_item يعمل بشكل صحيح. إذا فشل add_item، سيفشل remove_item أيضاً، وهذا يجعل من الصعب تحديد مصدر المشكلة الحقيقية. في فرق كبيرة، هذا النوع من الاعتمادية يمكن أن يسبب كوارث عندما يحاول مطورون مختلفون تعديل نفس الكود.

الفخ الرابع هو "التجاهل المتعمد للاختبارات الفاشلة". عندما يكون هناك ضغط زمني، يميل المطورون لتجاهل الاختبارات التي تفشل مؤقتاً، خاصة إذا كانوا يعتقدون أنها ستُصلح لاحقاً. المشكلة أن "لاحقاً" لا يأتي أبداً، وسرعان ما تجد نفسك مع مجموعة من الاختبارات الفاشلة التي لا أحد يعرف لماذا فشلت. هذا يدمر الفائدة الأساسية لـTDD، وهي توفير شبكة أمان للكود.

التوازن العملي: كيف تستفيد من TDD دون أن تصبح عبداً له؟

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

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

ثانياً، يجب أن نفهم أن الاختبارات ليست كلها متساوية. هناك هرم للاختبارات يجب أن نتبعه:

• •اختبارات الوحدة (Unit Tests): سريعة، تركز على دالة أو كلاس واحد. يجب أن تكون الأغلبية.
• •اختبارات التكامل (Integration Tests): تختبر كيفية تفاعل عدة مكونات معاً.
• •اختبارات النظام (System Tests): تختبر النظام كاملاً من واجهة المستخدم إلى قاعدة البيانات.
• •اختبارات واجهة المستخدم (UI Tests): بطيئة ومكلفة، يجب أن تكون الأقل عدداً.

في معظم المشاريع، يجب أن يكون لديك ٧٠٪ اختبارات وحدة، ٢٠٪ اختبارات تكامل، و١٠٪ اختبارات نظام وواجهة مستخدم. المشكلة أن الكثير من الفرق تبدأ من الأعلى (واجهة المستخدم) بدلاً من الأسفل، وهذا يجعل الاختبارات بطيئة ومعقدة. لنأخذ مثالاً عملياً على تطبيق TDD الجزئي في مشروع حقيقي.

لنفترض أنك تعمل على نظام إدارة محتوى، والمهمة هي إضافة خاصية البحث عن المقالات. بدلاً من كتابة الاختبار أولاً، يمكنك كتابة الكود الأساسي ثم الاختبار بعده مباشرة:

# search.py
def search_articles(query, articles):
 return [article for article in articles if query.lower() in article['title'].lower()]

# test_search.py
import pytest
from search import search_articles

def test_search_returns_matching_articles():
 articles = [
 {'title': 'Python Tips', 'content': '...'},
 {'title': 'JavaScript Tricks', 'content': '...'}
 ]
 assert search_articles('python', articles) == [{'title': 'Python Tips', 'content': '...'}]

def test_search_is_case_insensitive():
 articles = [{'title': 'Python Tips', 'content': '...'}]
 assert search_articles('PYTHON', articles) == articles

def test_search_returns_empty_list_when_no_match():
 articles = [{'title': 'Python Tips', 'content': '...'}]
 assert search_articles('Java', articles) == []

هذا الأسلوب يعطيك فائدة TDD (الكود مغطى باختبارات) دون التعقيد الزائد لكتابتها أولاً. كما أنك تستطيع التركيز على كتابة الكود بالطريقة التي تناسبك، ثم التفكير في الاختبارات بعد ذلك.

ثالثاً، يجب أن نتعلم متى نتجاهل TDD تماماً. هناك حالات يكون فيها تطبيق TDD مضيعة للوقت، مثل:

• •النماذج الأولية (Prototypes) التي ستُرمى لاحقاً.
• •الكود الذي يعتمد بشكل كبير على واجهات المستخدم أو APIs خارجية غير مستقرة.
• •المشاريع الصغيرة جداً أو التي لن تُستخدم إلا مرة واحدة.
• •المهام التي تتطلب الكثير من البحث والاستكشاف قبل كتابة الكود.

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

دراسة حالة: كيف طبقنا TDD في مشروع حقيقي دون أن نتحول إلى عبيد له؟

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

• •خوارزمية التوصية نفسها (القلب النابض للنظام).
• •العمليات المالية مثل حساب الخصومات والضرائب.
• •التكامل مع بوابات الدفع الخارجية.
• •التحقق من صحة البيانات المدخلة من المستخدمين.

بالنسبة للأجزاء الأخرى، مثل واجهات المستخدم والـAPIs البسيطة، كتبنا الاختبارات بعد كتابة الكود مباشرة. كما استخدمنا أدوات مثل Cypress لكتابة اختبارات واجهة المستخدم فقط للسيناريوهات الرئيسية، بدلاً من تغطية كل زر وكل رابط.

النتيجة كانت مذهلة: قللنا عدد البَجَّات في الإنتاج بنسبة ٦٠٪ مقارنة بمشاريع سابقة، دون زيادة كبيرة في وقت التطوير. السر كان في التركيز على ما يهم حقاً، وليس على تطبيق TDD بشكل أعمى. مثلاً، بالنسبة لخوارزمية التوصية، كتبنا اختبارات تغطي الحالات التالية:

describe('Recommendation Engine', () => {
 it('should recommend products from the same category', () => {
 const engine = new RecommendationEngine();
 const products = [
 { id: '1', category: 'electronics', name: 'Laptop' },
 { id: '2', category: 'electronics', name: 'Mouse' },
 { id: '3', category: 'books', name: 'Novel' }
 ];
 const recommendati engine.recommend('1', products);
 expect(recommendations).toContainEqual({ id: '2', category: 'electronics', name: 'Mouse' });
 expect(recommendations).not.toContainEqual({ id: '3', category: 'books', name: 'Novel' });
 });

 it('should not recommend out of stock products', () => {
 const engine = new RecommendationEngine();
 const products = [
 { id: '1', category: 'electronics', name: 'Laptop', inStock: false },
 { id: '2', category: 'electronics', name: 'Mouse', inStock: true }
 ];
 const recommendations = engine.recommend('1', products);
 expect(recommendations).toContainEqual({ id: '2', category: 'electronics', name: 'Mouse', inStock: true });
 expect(recommendations).not.toContainEqual({ id: '1', category: 'electronics', name: 'Laptop', inStock: false });
 });

 it('should handle empty product list gracefully', () => {
 const engine = new RecommendationEngine();
 const recommendations = engine.recommend('1', []);
 expect(recommendations).toEqual([]);
 });
});

هذه الاختبارات تغطي المنطق الأساسي للخوارزمية دون الدخول في تفاصيل واجهة المستخدم أو قواعد البيانات. كما أننا أضفنا اختبارات أداء للتأكد من أن الخوارزمية تعمل بسرعة حتى مع آلاف المنتجات. النتيجة كانت نظاماً مستقراً حتى مع زيادة عدد المستخدمين، وهذا ما جعل العميل سعيداً رغم أننا لم نطبق TDD بشكل كامل.

الخاتمة: نصيحة المهندس

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

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

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