اختبار C# للمبتدئين: من أين تبدأ في 2024

لماذا اختبار C# ليس مخيفًا بل مفيدًا؟

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

تخيل أنك قمت بتجميع آلية معقدة من آلاف القطع. ألن تقوم بتشغيلها بكامل طاقتها دون فحص كل مكون؟ هكذا الحال مع البرنامج: اختبار الوحدات C# يسمح لك بفحص كل "ترس" في الكود الخاص بك بشكل منفصل، دون انتظار انهيار النظام بأكمله في بيئة الإنتاج. في هذه المقالة، سنشرح اختبار C# من الصفر: من اختيار الإطار إلى كتابة أول اختبار ذي معنى. هيا بنا!

من أين تبدأ اختبار C#: إعداد البيئة

قبل كتابة الكود، دعنا نتأكد من أن لديك كل ما تحتاجه. لاختبار C# ستحتاج إلى:

\n
• Visual Studio 2022 (إصدار Community مجاني) أو JetBrains Rider (إذا كان لديك ترخيص).
\n
• .NET SDK (الإصدار 6 أو 7 أو 8 - أي إصدار LTS مناسب).
\n
• فهم أساسي للبرمجة كائنية التوجه في C#: الفئات، الدوال، الواجهات.
\n

عندما تكون البيئة جاهزة، قم بإنشاء مشروع جديد. أوصي بفصل الكود فورًا إلى مشروعين: المشروع الرئيسي (مكتبتك أو تطبيقك) ومشروع الاختبار. في Visual Studio يتم ذلك بالأمر: File → New → Project → xUnit Test Project (.NET Core) أو NUnit Test Project. لكننا سنذهب أبعد قليلاً ونشرح كلا الأداتين الشائعتين.

اختيار الإطار: NUnit مقابل xUnit

في عالم C# هناك "لاعبان" رئيسيان لكتابة اختبارات الوحدات: NUnit و xUnit. كلاهما يعمل بشكل ممتاز، لكن هناك فروق:

\n
• NUnit - كلاسيكي، قادم من Java (مشابه لـ JUnit). يحتوي على الخصائص [Test] و [SetUp] و [TearDown]. واضح جدًا للمبتدئين.
\n
• xUnit - إطار حديث من مبتكري ASP.NET. يستخدم [Fact] و [Theory]. يُعتبر أكثر "نقاءً" ويتكامل بشكل أفضل مع .NET Core.
\n

للمبتدئين، أنصح باستخدام xUnit - فهو أبسط، لا يتطلب خصائص إضافية، وأسهل للفهم. لكن إذا كان فريقك يستخدم NUnit - لا مشكلة، سنشرح كلا الخيارين.

أول اختبار وحدة في C#: كتابة الكود

لنفترض أن لدينا فئة آلة حاسبة بسيطة:

public class Calculator\n{\n    public int Add(int a, int b) => a + b;\n    \n    public int Divide(int a, int b)\n    {\n        if (b == 0)\n            throw new DivideByZeroException("لا يمكن القسمة على صفر!");\n        return a / b;\n    }\n}

الآن سنكتب اختبارات لهذه الفئة. سننشئ مشروع اختبار (xUnit) ونضيف مرجعًا للمشروع الرئيسي.

مثال اختبار باستخدام xUnit

using Xunit;\n\npublic class CalculatorTests\n{\n    [Fact]\n    public void Add_ShouldReturnSum_WhenTwoNumbers()\n    {\n        // Arrange\n        var calculator = new Calculator();\n        \n        // Act\n        var result = calculator.Add(3, 5);\n        \n        // Assert\n        Assert.Equal(8, result);\n    }\n    \n    [Fact]\n    public void Divide_ShouldThrowException_WhenDivideByZero()\n    {\n        var calculator = new Calculator();\n        \n        Assert.Throws<DivideByZeroException>(() => calculator.Divide(10, 0));\n    }\n}

لاحظ هيكل Arrange-Act-Assert (AAA). هذا هو المعيار الذهبي لكتابة الاختبارات: أولاً تجهيز البيانات، ثم تنفيذ الإجراء، ثم التحقق من النتيجة. احفظ هذا النمط - سينقذك من الفوضى