TDD في C#: توقف عن الخوف من الاختبارات وابدأ في كتابة كود لا تخجل منه

تعلم Python بسهولة دون إرهاق نظري. حل مهام عملية مع التحقق التلقائي واكتب الكود مباشرة في المتصفح.

لماذا "الاختبارات أولاً" ليست مازوخية بل قوة خارقة

\n\n

تخيل: أنت تكتب كودًا، كل شيء يعمل. أنت سعيد. بعد شهر تعود إلى المشروع، تغير سطرًا واحدًا - وكل شيء ينهار. مألوف؟ مرحبًا بك في نادي المطورين الذين لا يكتبون اختبارات. والآن تخيل واقعًا آخر: تغير الكود، تشغل الاختبارات - وبعد 10 ثوانٍ تعرف أن شيئًا لم ينكسر. هذا ليس سحرًا، هذا TDD (Test-Driven Development) - التطوير القائم على الاختبار.

\n\n

في هذه المقالة سنشرح TDD باستخدام C#. بدون نظرية مملة. فقط ممارسة، كود وحالات واقعية. إذا كنت تعتقد أن TDD مخصص لـ "المهندسين المعماريين النقيين" أو "وحوش المؤسسات" - فستتفاجأ. إنها أداة ستنقذ كودك وأعصابك.

\n\n

ما هو TDD وكيف يعمل Red-Green-Refactor

\n\n

TDD ليس عن الاختبار. إنه عن التصميم. أنت لا تكتب اختبارات بعد الكود، بل العكس: أولاً الاختبار، ثم الحد الأدنى من الكود الذي ينجح فيه، وبعد ذلك فقط إعادة الهيكلة. هذه الدورة تسمى Red-Green-Refactor:

\n\n

Red - نكتب اختبارًا سيفشل بالتأكيد (أحمر).
Green - نكتب الحد الأدنى من الكود ليجتاز الاختبار (أخضر).
Refactor - نحسن الكود دون تغيير سلوكه.

\n\n

يبدو غريبًا؟ دعنا نرى مثالاً. لنفترض أننا بحاجة إلى آلة حاسبة بطريقة الجمع. عادة نكتب الكلاس، ثم الاختبار. في TDD - العكس.

\n\n

الخطوة 1: Red - نكتب اختبارًا سيفشل

\n\n

using NUnit.Framework;\n\n[TestFixture]\npublic class CalculatorTests\n{\n    [Test]\n    public void Add_ShouldReturnSumOfTwoNumbers()\n    {\n        // Arrange\n        var calculator = new Calculator();\n        \n        // Act\n        var result = calculator.Add(2, 3);\n        \n        // Assert\n        Assert.AreEqual(5, result);\n    }\n}

\n\n

نشغله - الاختبار يفشل، لأن كلاس Calculator غير موجود. الأحمر طبيعي. الآن مهمتنا هي جعله أخضر.

\n\n

الخطوة 2: Green - الحد الأدنى من الكود ليجتاز الاختبار

\n\n

public class Calculator\n{\n    public int Add(int a, int b)\n    {\n        return a + b; // الحد الأدنى من التنفيذ\n    }\n}

\n\n

الاختبار أخضر. مرحى. لكن الكود لا يزال قبيحًا. ننتقل إلى الخطوة 3.

\n\n

الخطوة 3: Refactor - نحسن دون كسر

\n\n

في هذه المرحلة يمكننا إضافة تحقق، معالجة استثناءات أو تغيير البنية. الأهم - يجب أن تبقى الاختبارات خضراء.

\n\n

public class Calculator\n{\n    public int Add(int a, int b)\n    {\n        if (a < 0 || b < 0)\n            throw new ArgumentException("يُسمح فقط بالأرقام الموجبة");\n        return a + b;\n    }\n}

\n\n

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

\n\n