تست واحد (Unit Testing) در C#: اصول و پیاده‌سازی با NUnit/XUnit

در دنیای پرشتاب توسعه نرم‌افزار، اطمینان از کیفیت و پایداری کد، بیش از هر زمان دیگری اهمیت پیدا کرده است. تست واحد (Unit Testing) به عنوان یکی از ستون‌های اصلی توسعه نرم‌افزار مدرن، به برنامه‌نویسان کمک می‌کند تا کوچک‌ترین اجزای برنامه‌ی خود را به صورت مستقل آزمایش کرده و از صحت عملکرد آن‌ها اطمینان حاصل کنند. این رویکرد نه تنها به شناسایی زودهنگام باگ‌ها کمک می‌کند، بلکه فرآیند بازسازی کد (Refactoring) را تسهیل بخشیده و به مستندسازی ضمنی کد نیز می‌پردازد.

این مقاله، یک راهنمای جامع و تخصصی برای توسعه‌دهندگان C# است که قصد دارند با مفاهیم، اصول، و پیاده‌سازی تست واحد با استفاده از دو فریم‌ورک قدرتمند NUnit و XUnit آشنا شوند. ما از مقدمات شروع کرده، به سراغ پیاده‌سازی عملی می‌رویم و در نهایت بهترین روش‌ها و الگوهای رایج را بررسی خواهیم کرد تا بتوانید کدی پایدارتر و قابل اطمینان‌تر تولید کنید.

چرا تست واحد (Unit Testing) حیاتی است؟

تصور کنید در حال ساختن یک ساختمان هستید. اگر هر جزء کوچکی از ساختمان، مانند یک آجر یا یک لوله، قبل از قرار گرفتن در جای خود مورد آزمایش قرار نگیرد، احتمال فروپاشی ساختمان بسیار بالا خواهد بود. در توسعه نرم‌افزار نیز وضعیت مشابه است. هر “واحد” (Unit) در کد شما، که می‌تواند یک متد، یک کلاس یا حتی یک کامپوننت کوچک باشد، باید به صورت جداگانه آزمایش شود تا از عملکرد صحیح آن اطمینان حاصل شود. در ادامه به دلایلی می‌پردازیم که چرا تست واحد برای هر پروژه C# حیاتی است:

۱. شناسایی زودهنگام باگ‌ها

هرچه باگ‌ها زودتر در چرخه توسعه شناسایی شوند، هزینه رفع آن‌ها کمتر خواهد بود. تست واحد باگ‌ها را در سطح پایین‌ترین جزء کد (مثل یک متد) پیدا می‌کند، قبل از اینکه این باگ‌ها به سایر قسمت‌های سیستم سرایت کرده و تشخیص و رفع آن‌ها پیچیده‌تر شود.

۲. بهبود کیفیت و قابلیت نگهداری کد

نوشتن تست‌های واحد، توسعه‌دهندگان را مجبور می‌کند تا کدی ماژولار، با کوپلینگ پایین و وظایف مشخص بنویسند. این امر به خودی خود منجر به کدی با کیفیت بالاتر و قابلیت نگهداری آسان‌تر می‌شود. کدهای تست‌پذیر معمولاً کدهایی هستند که طراحی بهتری دارند.

۳. تسهیل فرآیند بازسازی (Refactoring)

بازسازی کد، فرآیند بهبود ساختار داخلی کد بدون تغییر در رفتار خارجی آن است. وجود مجموعه کاملی از تست‌های واحد، به توسعه‌دهنده این اطمینان را می‌دهد که پس از تغییرات ساختاری، عملکرد اصلی کد همچنان بدون نقص باقی مانده است. این تست‌ها به عنوان یک شبکه ایمنی عمل می‌کنند.

۴. مستندسازی ضمنی و معتبر

تست‌های واحد می‌توانند به عنوان مستنداتی زنده برای کد شما عمل کنند. با خواندن تست‌ها، توسعه‌دهندگان جدید می‌توانند به سرعت درک کنند که یک تابع یا کلاس خاص چه کاری انجام می‌دهد و در چه شرایطی باید رفتار خاصی داشته باشد. برخلاف مستندات متنی که ممکن است قدیمی شوند، تست‌ها همواره با کد همگام هستند.

۵. کاهش هزینه‌های بلندمدت پروژه

با شناسایی و رفع باگ‌ها در مراحل اولیه، از اتلاف وقت و منابع در مراحل بعدی توسعه (مانند تست‌های یکپارچه‌سازی یا تست‌های سیستم) جلوگیری می‌شود. این امر به کاهش کلی هزینه‌های توسعه و نگهداری نرم‌افزار در بلندمدت منجر می‌شود.

۶. افزایش اعتماد به نفس تیم توسعه

تیم توسعه با داشتن تست‌های واحد قابل اعتماد، اعتماد به نفس بیشتری در اعمال تغییرات، افزودن ویژگی‌های جدید یا بازسازی کد خواهند داشت. این اعتماد به نفس، سرعت توسعه را افزایش داده و ریسک پیاده‌سازی را کاهش می‌دهد.

۷. پشتیبانی از توسعه مبتنی بر تست (TDD)

تست واحد سنگ بنای توسعه مبتنی بر تست (Test-Driven Development – TDD) است. در TDD، ابتدا تست نوشته می‌شود، سپس کد برای پاس کردن آن تست پیاده‌سازی می‌گردد. این رویکرد به طور فعال کیفیت طراحی و کد را بهبود می‌بخشد و اطمینان از پوشش کامل تست را فراهم می‌کند.

اصول تست واحد مؤثر

برای اینکه تست‌های واحد شما واقعاً مفید و مؤثر باشند، باید از اصول خاصی پیروی کنند. اصول F.I.R.S.T یک راهنمای عالی برای نوشتن تست‌های واحد با کیفیت ارائه می‌دهد:

۱. Fast (سریع)

تست‌های واحد باید به سرعت اجرا شوند. یک مجموعه بزرگ از تست‌های واحد باید در عرض چند ثانیه یا حداکثر چند دقیقه اجرا شود. اگر تست‌ها کند باشند، توسعه‌دهندگان تمایل کمتری به اجرای مکرر آن‌ها خواهند داشت و این موضوع هدف اصلی تست واحد را نقض می‌کند. سرعت بالا امکان اجرای مکرر تست‌ها را در طول چرخه توسعه و همچنین در سیستم‌های CI/CD فراهم می‌آورد.

۲. Independent / Isolated (مستقل / ایزوله)

هر تست واحد باید مستقل از سایر تست‌ها باشد. ترتیب اجرای تست‌ها نباید بر نتیجه آن‌ها تأثیر بگذارد. این به معنای عدم وابستگی بین تست‌ها و عدم اشتراک‌گذاری حالت (state) بین آن‌ها است. هر تست باید بتواند بدون نیاز به اجرای تست‌های دیگر یا تکیه بر نتایج آن‌ها، به طور مستقل عمل کند. این ویژگی تشخیص دلیل شکست یک تست را بسیار آسان‌تر می‌کند.

۳. Repeatable (قابل تکرار)

یک تست واحد باید هر بار که اجرا می‌شود، نتایج یکسانی بدهد، صرف نظر از محیط اجرا یا زمان اجرا. این بدان معناست که تست‌ها نباید به عواملی مانند زمان جاری، تاریخ، یا تنظیمات محیطی خارجی وابسته باشند که می‌توانند منجر به شکست‌های ناپایدار (flaky tests) شوند. قابلیت تکرارپذیری، اعتماد به تست‌ها را افزایش می‌دهد.

۴. Self-validating (خود-اعتبارسنج)

یک تست باید بتواند به تنهایی مشخص کند که آیا موفق بوده یا شکست خورده است، بدون نیاز به بررسی دستی خروجی یا لاگ‌ها. این کار معمولاً از طریق عبارات Asssert انجام می‌شود که نتایج واقعی را با نتایج مورد انتظار مقایسه می‌کنند. نتیجه تست باید یک بولی ساده (True/False یا Pass/Fail) باشد.

۵. Thorough / Timely (کامل / به موقع)

تست‌ها باید تا حد امکان کامل باشند و تمام حالت‌های ممکن، ورودی‌های معتبر و نامعتبر، و شرایط مرزی را پوشش دهند. علاوه بر این، تست‌ها باید به موقع نوشته شوند؛ ایده آل این است که قبل از نوشتن کد اصلی (در رویکرد TDD) یا حداقل بلافاصله پس از آن نوشته شوند تا اطمینان حاصل شود که هر تکه کد جدید دارای پوشش تستی مناسب است.

الگوی Arrange-Act-Assert (AAA)

یکی از رایج‌ترین الگوها برای سازماندهی کد تست واحد، الگوی Arrange-Act-Assert (AAA) است. این الگو کد تست را به سه بخش منطقی تقسیم می‌کند:

• Arrange (تنظیم): در این بخش، تمام پیش‌نیازهای لازم برای اجرای تست آماده می‌شود. این شامل مقداردهی اولیه به اشیاء، تنظیم وابستگی‌ها، و آماده‌سازی داده‌های ورودی است.
• Act (اجرا): در این بخش، عملیات مورد نظر که قرار است تست شود، فراخوانی می‌شود. این معمولاً شامل فراخوانی یک متد یا ویژگی از کلاس تحت آزمایش است.
• Assert (اعتبارسنجی): در این بخش، نتیجه عملیات اجرا شده با مقدار مورد انتظار مقایسه و اعتبارسنجی می‌شود. از توابع `Assert` فریم‌ورک تست برای انجام این مقایسات استفاده می‌شود.

[Test]
public void Add_TwoNumbers_ReturnsCorrectSum()
{
    // Arrange
    var calculator = new Calculator();
    int num1 = 5;
    int num2 = 10;
    int expectedSum = 15;

    // Act
    int actualSum = calculator.Add(num1, num2);

    // Assert
    Assert.AreEqual(expectedSum, actualSum);
}

انتخاب فریم‌ورک تست: NUnit در مقابل XUnit

اکوسیستم .NET دارای چندین فریم‌ورک تست واحد قدرتمند است که هر کدام ویژگی‌ها و فلسفه‌های خاص خود را دارند. NUnit و XUnit از محبوب‌ترین و پراستفاده‌ترین فریم‌ورک‌ها در C# هستند. درک تفاوت‌ها و شباهت‌های آن‌ها به شما کمک می‌کند تا بهترین گزینه را برای پروژه خود انتخاب کنید.

NUnit: ریشه‌دار و غنی از ویژگی‌ها

NUnit یکی از قدیمی‌ترین و جاافتاده‌ترین فریم‌ورک‌های تست در اکوسیستم .NET است که از Junit (فریم‌ورک تست جاوا) الهام گرفته شده است. این فریم‌ورک به خاطر ویژگی‌های غنی و پشتیبانی جامعه وسیع خود شناخته شده است.

XUnit: مدرن، سبک‌وزن و قابل توسعه

XUnit.net یک فریم‌ورک تست نسبتاً جدیدتر است که توسط برخی از توسعه‌دهندگان اولیه NUnit با رویکردی مدرن‌تر و فلسفه‌ای متفاوت ایجاد شده است. XUnit بر سادگی، قابلیت توسعه و موازی‌سازی تست‌ها تمرکز دارد.

شباهت‌ها

• هر دو فریم‌ورک از ویژگی‌ها (Attributes) برای علامت‌گذاری متدهای تست استفاده می‌کنند.
• هر دو از کنسول رانر، ویژوال استودیو Test Explorer و ابزارهای CI/CD پشتیبانی می‌کنند.
• هر دو دارای مجموعه‌ای غنی از توابع Assert برای اعتبارسنجی نتایج هستند.
• هر دو از تست‌های پارامتری (Parameterized Tests) پشتیبانی می‌کنند.
• هر دو فریم‌ورک اوپن سورس بوده و به صورت پکیج‌های NuGet در دسترس هستند.

تفاوت‌های کلیدی

۱. فلسفه و ساختار تست

• NUnit: از مفهوم `TestFixture` (کلاس تست) استفاده می‌کند که با ویژگی `[TestFixture]` مشخص می‌شود. هر کلاس تست می‌تواند شامل چندین متد تست با ویژگی `[Test]` باشد. این فریم‌ورک بر ایجاد نمونه‌های جدید از کلاس تست برای هر متد `[Test]` به صورت پیش‌فرض تمرکز ندارد.
• XUnit: مفهوم `TestFixture` را ندارد. هر کلاس حاوی تست‌ها، به صورت پیش‌فرض، یک نمونه جدید برای هر متد `[Fact]` یا `[Theory]` ایجاد می‌کند. این رویکرد به طور طبیعی تست‌ها را ایزوله‌تر می‌کند و برای مدیریت وابستگی‌ها از سازنده (constructor) کلاس تست استفاده می‌شود.

۲. ویژگی‌های Setup و Teardown

• NUnit: دارای ویژگی‌های اختصاصی مانند `[SetUp]` (اجرا قبل از هر تست), `[TearDown]` (اجرا بعد از هر تست), `[OneTimeSetUp]` (اجرا یک بار قبل از تمام تست‌های کلاس) و `[OneTimeTearDown]` (اجرا یک بار بعد از تمام تست‌های کلاس) است.
• XUnit: رویکرد متفاوتی برای Setup و Teardown دارد. برای Setup/Teardown در سطح هر تست، از سازنده و متد `Dispose()` در کلاس تست (با پیاده‌سازی `IDisposable`) استفاده می‌شود. برای Setup/Teardown در سطح کلاس یا مجموعه تست، از `IClassFixture` یا `CollectionDefinition` استفاده می‌کند.

۳. تست‌های پارامتری

• NUnit: از ویژگی `[TestCase]` به وفور استفاده می‌کند که ورودی‌های تست را مستقیماً به متد تست پاس می‌دهد. همچنین دارای `[ValueSource]`، `[Random]`، `[Range]` و… است.
• XUnit: از `[Theory]` به همراه `[InlineData]`، `[MemberData]` یا `[ClassData]` استفاده می‌کند. `[Theory]` به این معناست که تست برای هر مجموعه داده فراهم شده، یک بار اجرا می‌شود و داده‌ها را به عنوان آرگومان به متد تست می‌فرستد.

۴. اجرای موازی تست‌ها

• NUnit: از NUnit 3 به بعد، پشتیبانی قوی از اجرای موازی تست‌ها (در سطح TestFixture یا در سطح متد) اضافه شده است.
• XUnit: از ابتدا با تمرکز بر اجرای موازی تست‌ها طراحی شده است. XUnit به صورت پیش‌فرض تست‌ها را موازی اجرا می‌کند (مگر اینکه Explicitly پیکربندی شود) که می‌تواند زمان اجرای مجموعه تست‌های بزرگ را به طرز چشمگیری کاهش دهد.

۵. گزارش‌دهی خروجی

• NUnit: از `Console.WriteLine` برای چاپ خروجی در حین اجرای تست‌ها پشتیبانی می‌کند.
• XUnit: برای مدیریت خروجی تست، از `ITestOutputHelper` استفاده می‌کند که از طریق تزریق وابستگی (Dependency Injection) در سازنده کلاس تست در دسترس است. این رویکرد بهتری برای مدیریت خروجی در محیط‌های تست موازی است.

چه زمانی کدام فریم‌ورک را انتخاب کنیم؟

• NUnit:
  • اگر در حال کار بر روی یک پروژه قدیمی‌تر هستید که قبلاً از NUnit استفاده می‌کرده است.
  • اگر به ویژگی‌های Setup/Teardown واضح و مشخص NUnit نیاز دارید.
  • اگر با سینتکس آن راحت‌تر هستید و به مجموعه‌ای جامع از Assertها نیاز دارید.
• XUnit:
  • اگر در حال شروع یک پروژه جدید هستید و به دنبال یک فریم‌ورک مدرن و سبک‌وزن هستید.
  • اگر اجرای موازی تست‌ها برای شما اولویت دارد.
  • اگر رویکرد آن برای ایزوله کردن تست‌ها (ایجاد نمونه جدید برای هر تست) و مدیریت Setup/Teardown از طریق سازنده/Dispose را ترجیح می‌دهید.
  • اگر می‌خواهید از بهترین شیوه‌های توسعه مبتنی بر تست (TDD) پیروی کنید.

در نهایت، انتخاب بین NUnit و XUnit اغلب به ترجیح شخصی تیم، تجربه قبلی و نیازهای خاص پروژه بستگی دارد. هر دو فریم‌ورک ابزارهای قدرتمندی برای نوشتن تست‌های واحد مؤثر در اختیار شما قرار می‌دهند.

پیاده‌سازی تست واحد با NUnit

در این بخش، به صورت عملی نحوه پیاده‌سازی تست واحد با استفاده از فریم‌ورک NUnit را بررسی خواهیم کرد. ابتدا یک پروژه تست ایجاد کرده و سپس مثال‌هایی از تست‌های ساده و پیشرفته‌تر ارائه می‌دهیم.

تنظیمات اولیه پروژه NUnit

1. ایجاد پروژه جدید: در Visual Studio، یک پروژه جدید از نوع “Class Library” (کتابخانه کلاس) برای کد اصلی خود ایجاد کنید (مثلاً `MyApplication.Core`). سپس یک پروژه جدید از نوع “NUnit Test Project” یا “xUnit Test Project” (برای هر دو فریم‌ورک مراحل اولیه مشابه است) ایجاد کنید (مثلاً `MyApplication.Core.Tests`). اطمینان حاصل کنید که پروژه تست به پروژه کد اصلی شما ارجاع (Reference) دارد.
2. نصب پکیج NuGet: در پروژه تست خود، پکیج `NUnit` و `NUnit3TestAdapter` را از NuGet نصب کنید. `NUnit` هسته فریم‌ورک تست و `NUnit3TestAdapter` به Visual Studio اجازه می‌دهد تا تست‌های NUnit را کشف و اجرا کند.

// نصب از طریق Package Manager Console:
// Install-Package NUnit
// Install-Package NUnit3TestAdapter
// Install-Package Microsoft.NET.Test.Sdk

ساختار پایه تست NUnit

در NUnit، کلاس‌های تست با ویژگی `[TestFixture]` و متدهای تست با ویژگی `[Test]` مشخص می‌شوند. متدهای `Assert` برای اعتبارسنجی نتایج استفاده می‌شوند.

مثال ۱: یک ماشین حساب ساده

فرض کنید کلاس `Calculator` زیر را داریم:

// Project: MyApplication.Core
namespace MyApplication.Core
{
    public class Calculator
    {
        public int Add(int a, int b)
        {
            return a + b;
        }

        public int Subtract(int a, int b)
        {
            return a - b;
        }

        public int Multiply(int a, int b)
        {
            return a * b;
        }

        public double Divide(int a, int b)
        {
            if (b == 0)
            {
                throw new ArgumentException("Cannot divide by zero.");
            }
            return (double)a / b;
        }
    }
}

اکنون، کلاس تست برای `Calculator` را در پروژه `MyApplication.Core.Tests` می‌نویسیم:

// Project: MyApplication.Core.Tests
using NUnit.Framework;
using MyApplication.Core; // ارجاع به کلاس اصلی

namespace MyApplication.Core.Tests
{
    [TestFixture] // مشخص می‌کند که این یک کلاس تست NUnit است
    public class CalculatorTests
    {
        private Calculator _calculator; // نمونه‌ای از کلاس تحت تست

        [SetUp] // این متد قبل از هر تست اجرا می‌شود
        public void Setup()
        {
            _calculator = new Calculator();
        }

        [Test] // مشخص می‌کند که این یک متد تست است
        public void Add_TwoPositiveNumbers_ReturnsCorrectSum()
        {
            // Arrange
            int num1 = 5;
            int num2 = 10;
            int expectedSum = 15;

            // Act
            int actualSum = _calculator.Add(num1, num2);

            // Assert
            Assert.AreEqual(expectedSum, actualSum);
        }

        [Test]
        public void Subtract_PositiveNumbers_ReturnsCorrectDifference()
        {
            // Arrange
            int num1 = 20;
            int num2 = 7;
            int expectedDifference = 13;

            // Act
            int actualDifference = _calculator.Subtract(num1, num2);

            // Assert
            Assert.AreEqual(expectedDifference, actualDifference);
        }

        [Test]
        public void Multiply_PositiveNumbers_ReturnsCorrectProduct()
        {
            // Arrange
            int num1 = 6;
            int num2 = 7;
            int expectedProduct = 42;

            // Act
            int actualProduct = _calculator.Multiply(num1, num2);

            // Assert
            Assert.AreEqual(expectedProduct, actualProduct);
        }
    }
}

ویژگی‌های پیشرفته NUnit

۱. متدهای Setup و Teardown

NUnit امکان اجرای کد قبل یا بعد از تست‌ها را فراهم می‌کند:

• `[SetUp]`: اجرا قبل از هر متد `[Test]` در `[TestFixture]`.
• `[TearDown]`: اجرا بعد از هر متد `[Test]` در `[TestFixture]`.
• `[OneTimeSetUp]`: اجرا یک بار قبل از شروع تمام متدهای `[Test]` در `[TestFixture]`. مناسب برای مقداردهی اولیه منابع سنگین.
• `[OneTimeTearDown]`: اجرا یک بار بعد از اتمام تمام متدهای `[Test]` در `[TestFixture]`. مناسب برای آزادسازی منابع.

[TestFixture]
public class AdvancedCalculatorTests
{
    private Calculator _calculator;
    private static List<string> _logs; // مثال برای OneTimeSetUp/Teardown

    [OneTimeSetUp]
    public static void OneTimeSetup()
    {
        // این متد یک بار قبل از تمام تست های این TestFixture اجرا می شود.
        _logs = new List<string>();
        _logs.Add("Test Fixture Started.");
        Console.WriteLine("OneTimeSetup executed.");
    }

    [SetUp]
    public void Setup()
    {
        // این متد قبل از هر تست اجرا می شود.
        _calculator = new Calculator();
        _logs.Add($"Test Setup for {TestContext.CurrentContext.Test.Name}");
        Console.WriteLine($"Setup executed for {TestContext.CurrentContext.Test.Name}");
    }

    [TearDown]
    public void Teardown()
    {
        // این متد بعد از هر تست اجرا می شود.
        _logs.Add($"Test Teardown for {TestContext.CurrentContext.Test.Name}");
        Console.WriteLine($"Teardown executed for {TestContext.CurrentContext.Test.Name}");
        _calculator = null; // منابع را آزاد می کند
    }

    [OneTimeTearDown]
    public static void OneTimeTeardown()
    {
        // این متد یک بار بعد از تمام تست های این TestFixture اجرا می شود.
        _logs.Add("Test Fixture Finished.");
        Console.WriteLine("OneTimeTeardown executed. Logs:");
        foreach (var log in _logs)
        {
            Console.WriteLine(log);
        }
    }

    [Test]
    public void Divide_ByZero_ThrowsArgumentException()
    {
        // Assert.Throws برای تست پرتاب استثناها
        Assert.Throws<ArgumentException>(() => _calculator.Divide(10, 0));
    }

    [Test]
    public void Divide_PositiveNumbers_ReturnsCorrectQuotient()
    {
        // Arrange, Act, Assert
        Assert.AreEqual(2.5, _calculator.Divide(5, 2), "Division of 5 by 2 should be 2.5");
    }
}

۲. تست‌های پارامتری با `[TestCase]`

NUnit به شما امکان می‌دهد یک متد تست را با مجموعه‌ای از ورودی‌های مختلف اجرا کنید. این کار با ویژگی `[TestCase]` انجام می‌شود.

[TestFixture]
public class ParameterizedCalculatorTests
{
    private Calculator _calculator;

    [SetUp]
    public void Setup()
    {
        _calculator = new Calculator();
    }

    [TestCase(1, 2, 3)] // ورودی ها: 1, 2. خروجی مورد انتظار: 3
    [TestCase(10, -5, 5)]
    [TestCase(0, 0, 0)]
    [TestCase(-10, -20, -30)]
    public void Add_VariousNumbers_ReturnsCorrectSum(int a, int b, int expected)
    {
        // Act
        int actual = _calculator.Add(a, b);

        // Assert
        Assert.AreEqual(expected, actual);
    }

    [TestCase(10, 2, 5.0)]
    [TestCase(10, 3, 3.33, TestName = "Divide by 3")] // نامگذاری تست
    public void Divide_VariousNumbers_ReturnsCorrectQuotient(int a, int b, double expected)
    {
        // Act
        double actual = _calculator.Divide(a, b);

        // Assert
        Assert.AreEqual(expected, actual, 0.01); // 0.01 خطای مجاز برای اعداد اعشاری
    }
}

۳. سایر Assertهای مفید

NUnit طیف وسیعی از متدهای `Assert` را برای سناریوهای مختلف فراهم می‌کند:

• `Assert.IsTrue(condition)` / `Assert.IsFalse(condition)`
• `Assert.IsNull(obj)` / `Assert.IsNotNull(obj)`
• `Assert.Contains(expected, collection)`
• `Assert.IsEmpty(collection)` / `Assert.IsNotEmpty(collection)`
• `StringAssert.Contains(substring, text)`
• `CollectionAssert.AreEqual(expectedCollection, actualCollection)`
• `Assert.That(actual, Is.EqualTo(expected))` – مدل Constraints (یک روش انعطاف‌پذیرتر)

[TestFixture]
public class OtherAssertTests
{
    [Test]
    public void StringContainsExpectedSubstring()
    {
        string text = "Hello NUnit World";
        StringAssert.Contains("NUnit", text);
        Assert.That(text, Does.Contain("World")); // استفاده از Constraints Model
    }

    [Test]
    public void ListContainsSpecificItem()
    {
        var numbers = new List<int> { 1, 2, 3, 4, 5 };
        CollectionAssert.Contains(numbers, 3);
        Assert.That(numbers, Does.Contain(5));
    }

    [Test]
    public void ObjectIsNotNull()
    {
        object obj = new object();
        Assert.IsNotNull(obj);
    }
}

پیاده‌سازی تست واحد با XUnit

در این بخش، به سراغ پیاده‌سازی تست واحد با استفاده از فریم‌ورک XUnit.net می‌رویم. XUnit رویکردی کمی متفاوت با NUnit دارد که بر سادگی و موازی‌سازی تست‌ها تمرکز دارد.

تنظیمات اولیه پروژه XUnit

1. ایجاد پروژه جدید: مشابه NUnit، یک پروژه “Class Library” برای کد اصلی و یک پروژه “xUnit Test Project” (با استفاده از قالب مربوطه در Visual Studio) برای تست‌ها ایجاد کنید (مثلاً `MyApplication.Core.Tests.XUnit`). ارجاع پروژه تست به پروژه اصلی را فراموش نکنید.
2. نصب پکیج NuGet: در پروژه تست خود، پکیج `xunit` و `xunit.runner.visualstudio` را از NuGet نصب کنید. `xunit` هسته فریم‌ورک تست و `xunit.runner.visualstudio` به Visual Studio اجازه می‌دهد تا تست‌های xUnit را کشف و اجرا کند.

// نصب از طریق Package Manager Console:
// Install-Package xunit
// Install-Package xunit.runner.visualstudio
// Install-Package Microsoft.NET.Test.Sdk

ساختار پایه تست XUnit

XUnit از ویژگی `[Fact]` برای مشخص کردن متدهای تست استفاده می‌کند. بر خلاف NUnit، نیازی به ویژگی `[TestFixture]` برای کلاس‌های تست نیست؛ هر کلاس عمومی (public) که متدهای `[Fact]` یا `[Theory]` داشته باشد، به عنوان یک کلاس تست در نظر گرفته می‌شود. XUnit برای هر متد تست، یک نمونه جدید از کلاس تست ایجاد می‌کند که به ایزوله‌سازی کمک می‌کند.

مثال ۱: ماشین حساب ساده (بازنگری)

با استفاده از همان کلاس `Calculator` از بخش قبل، کلاس تست برای آن را در XUnit می‌نویسیم:

// Project: MyApplication.Core.Tests.XUnit
using Xunit;
using MyApplication.Core; // ارجاع به کلاس اصلی

namespace MyApplication.Core.Tests.XUnit
{
    public class CalculatorTestsXUnit // نیازی به [TestFixture] نیست
    {
        private readonly Calculator _calculator; // نمونه ایزوله شده برای هر تست

        // سازنده برای Setup (جایگزین [SetUp] در NUnit)
        public CalculatorTestsXUnit()
        {
            _calculator = new Calculator();
        }

        [Fact] // مشخص می کند که این یک متد تست (بدون پارامتر) است
        public void Add_TwoPositiveNumbers_ReturnsCorrectSum()
        {
            // Arrange
            int num1 = 5;
            int num2 = 10;
            int expectedSum = 15;

            // Act
            int actualSum = _calculator.Add(num1, num2);

            // Assert
            Assert.Equal(expectedSum, actualSum);
        }

        [Fact]
        public void Subtract_PositiveNumbers_ReturnsCorrectDifference()
        {
            // Arrange
            int num1 = 20;
            int num2 = 7;
            int expectedDifference = 13;

            // Act
            int actualDifference = _calculator.Subtract(num1, num2);

            // Assert
            Assert.Equal(expectedDifference, actualDifference);
        }

        [Fact]
        public void Multiply_PositiveNumbers_ReturnsCorrectProduct()
        {
            // Arrange
            int num1 = 6;
            int num2 = 7;
            int expectedProduct = 42;

            // Act
            int actualProduct = _calculator.Multiply(num1, num2);

            // Assert
            Assert.Equal(expectedProduct, actualProduct);
        }
    }
}

ویژگی‌های پیشرفته XUnit

۱. مدیریت Setup و Teardown

به دلیل ایجاد نمونه جدید از کلاس تست برای هر `[Fact]` یا `[Theory]`، XUnit برای Setup و Teardown از الگوهای متفاوتی استفاده می‌کند:

• Setup در سطح تست: از سازنده (constructor) کلاس تست استفاده می‌شود.
• Teardown در سطح تست: با پیاده‌سازی اینترفیس `IDisposable` در کلاس تست و استفاده از متد `Dispose()`.
• Setup/Teardown در سطح کلاس/مجموعه: با استفاده از `IClassFixture` یا `CollectionDefinition`.

using Xunit;
using System;
using Xunit.Abstractions; // برای خروجی لاگ

namespace MyApplication.Core.Tests.XUnit
{
    public class AdvancedCalculatorTestsXUnit : IDisposable // برای Teardown
    {
        private readonly Calculator _calculator;
        private readonly ITestOutputHelper _output; // برای چاپ خروجی در گزارش تست

        // Setup (اجرا برای هر تست)
        public AdvancedCalculatorTestsXUnit(ITestOutputHelper output)
        {
            _calculator = new Calculator();
            _output = output;
            _output.WriteLine("CalculatorTestsXUnit constructor (Setup) executed.");
        }

        // Teardown (اجرا برای هر تست)
        public void Dispose()
        {
            _output.WriteLine("CalculatorTestsXUnit Dispose (Teardown) executed.");
            // منابع را آزاد می کند
            // _calculator = null; (نیازی به null کردن نیست، چون GC مدیریت می کند)
        }

        [Fact]
        public void Divide_ByZero_ThrowsArgumentException()
        {
            // Assert.Throws برای تست پرتاب استثناها
            Assert.Throws<ArgumentException>(() => _calculator.Divide(10, 0));
            _output.WriteLine("Divide_ByZero_ThrowsArgumentException test completed.");
        }

        [Fact]
        public void Divide_PositiveNumbers_ReturnsCorrectQuotient()
        {
            // Act
            double actual = _calculator.Divide(5, 2);

            // Assert
            Assert.Equal(2.5, actual);
            _output.WriteLine("Divide_PositiveNumbers_ReturnsCorrectQuotient test completed.");
        }
    }
}

۲. تست‌های پارامتری با `[Theory]` و `[InlineData]`

XUnit از `[Theory]` برای تست‌های پارامتری استفاده می‌کند که داده‌ها را از منابع مختلف (مانند `[InlineData]`) دریافت می‌کند.

using Xunit;
using MyApplication.Core;

namespace MyApplication.Core.Tests.XUnit
{
    public class ParameterizedCalculatorTestsXUnit
    {
        private readonly Calculator _calculator;

        public ParameterizedCalculatorTestsXUnit()
        {
            _calculator = new Calculator();
        }

        [Theory] // نشان می دهد که این تست پارامتری است
        [InlineData(1, 2, 3)] // داده های ورودی
        [InlineData(10, -5, 5)]
        [InlineData(0, 0, 0)]
        [InlineData(-10, -20, -30)]
        public void Add_VariousNumbers_ReturnsCorrectSum(int a, int b, int expected)
        {
            // Act
            int actual = _calculator.Add(a, b);

            // Assert
            Assert.Equal(expected, actual);
        }

        [Theory]
        [InlineData(10, 2, 5.0)]
        [InlineData(10, 3, 3.33)]
        public void Divide_VariousNumbers_ReturnsCorrectQuotient(int a, int b, double expected)
        {
            // Act
            double actual = _calculator.Divide(a, b);

            // Assert
            Assert.Equal(expected, actual, 2); // دقت تا 2 رقم اعشار
        }
    }
}

۳. سایر Assertهای مفید در XUnit

XUnit نیز دارای مجموعه کاملی از متدهای `Assert` است:

• `Assert.True(condition)` / `Assert.False(condition)`
• `Assert.Null(obj)` / `Assert.NotNull(obj)`
• `Assert.Contains(expected, collection)`
• `Assert.Empty(collection)`
• `Assert.Equal(expected, actual)` – (برای انواع مختلف داده)
• `Assert.Collection(collection, …)` – برای بررسی محتوای دقیق کالکشن‌ها
• `Assert.StartsWith(expectedSubstring, actualString)` / `Assert.EndsWith(…)`
• `Assert.Matches(regexPattern, actualString)`

using Xunit;
using System.Collections.Generic;

namespace MyApplication.Core.Tests.XUnit
{
    public class OtherAssertTestsXUnit
    {
        [Fact]
        public void StringContainsExpectedSubstring()
        {
            string text = "Hello XUnit World";
            Assert.Contains("XUnit", text);
        }

        [Fact]
        public void ListContainsSpecificItem()
        {
            var numbers = new List<int> { 1, 2, 3, 4, 5 };
            Assert.Contains(3, numbers);
        }

        [Fact]
        public void ObjectIsNotNull()
        {
            object obj = new object();
            Assert.NotNull(obj);
        }

        [Fact]
        public void CollectionHasSpecificItemsAndOrder()
        {
            var names = new List<string> { "Alice", "Bob", "Charlie" };
            Assert.Collection(names,
                item => Assert.Equal("Alice", item),
                item => Assert.Equal("Bob", item),
                item => Assert.Equal("Charlie", item)
            );
        }
    }
}

استفاده از Test Doubles (Mocks, Stubs) در تست واحد

در دنیای واقعی، بسیاری از کلاس‌ها و متدهایی که می‌خواهیم تست کنیم، وابستگی‌هایی به سایر کلاس‌ها یا منابع خارجی (مانند پایگاه داده، سرویس‌های وب، سیستم فایل) دارند. تست واحد باید تا حد امکان ایزوله باشد و فقط منطق کسب‌وکار واحد مورد نظر را آزمایش کند، نه وابستگی‌های آن را. اینجا است که “Test Doubles” وارد می‌شوند.

Test Doubles چیستند؟

Test Double یک شیء جایگزین برای یک شیء واقعی است که در حین اجرای تست استفاده می‌شود. هدف اصلی آن “ایزوله کردن” کد تحت آزمایش از وابستگی‌هایش است تا بتوانیم رفتار آن وابستگی‌ها را کنترل کرده و از تأثیرات جانبی خارجی جلوگیری کنیم.

چرا از Test Doubles استفاده کنیم؟

• ایزوله کردن تست: اطمینان از اینکه شکست تست فقط به دلیل باگ در واحد تحت آزمایش است، نه در وابستگی‌های آن.
• کنترل رفتار: می‌توانیم سناریوهای مختلفی را شبیه‌سازی کنیم (مانند خطای شبکه، داده‌های خاص از پایگاه داده) که در محیط واقعی دشوار یا غیرممکن است.
• افزایش سرعت تست: جایگزینی عملیات‌های کند (مثل فراخوانی پایگاه داده) با نسخه‌های در حافظه.
• کاهش پیچیدگی تست: حذف نیاز به راه‌اندازی و مدیریت محیط‌های پیچیده برای وابستگی‌ها.

انواع Test Doubles

مارتین فاولر (Martin Fowler) انواع مختلفی از Test Doubles را تعریف کرده است:

1. Dummy Objects (اشیاء بی‌مصرف): اشیائی هستند که فقط به عنوان آرگومان پاس داده می‌شوند اما هرگز استفاده نمی‌شوند. معمولاً `null` یا یک نمونه خالی هستند و اهمیتی به محتوایشان نمی‌دهیم.
2. Fake Objects (اشیاء جعلی): پیاده‌سازی‌های عملیاتی هستند اما معمولاً دارای ساده‌سازی‌هایی هستند که آن‌ها را برای تولید مناسب نمی‌کند (مثلاً یک پیاده‌سازی در حافظه از یک پایگاه داده).
3. Stubs (استاب‌ها): اشیائی هستند که پاسخ‌های از پیش برنامه‌ریزی شده‌ای به فراخوانی‌ها ارائه می‌دهند. آن‌ها برای “فراهم کردن” داده‌ها یا مقادیر مورد نیاز واحد تحت آزمایش استفاده می‌شوند. استاب‌ها هیچ رفتاری را “بررسی” نمی‌کنند، فقط داده می‌دهند.
4. Spies (جاسوس‌ها): استاب‌هایی هستند که علاوه بر بازگرداندن مقادیر، اطلاعاتی در مورد چگونگی فراخوانی متدهایشان (مثلاً تعداد دفعات فراخوانی، آرگومان‌های ارسالی) جمع‌آوری می‌کنند.
5. Mocks (ماک‌ها): اشیائی هستند که رفتار مورد انتظار را برای متدهای خاصی از وابستگی‌ها تعریف می‌کنند و قادرند “بررسی” کنند که آیا آن متدها به تعداد دفعات مشخص و با آرگومان‌های صحیح فراخوانی شده‌اند یا خیر. ماک‌ها برای تست “تعاملات” بین واحدها استفاده می‌شوند.

استفاده از Mocking Frameworks: Moq

نوشتن Test Doubles به صورت دستی می‌تواند زمان‌بر و پیچیده باشد. فریم‌ورک‌های Mocking مانند Moq، NSubstitute، FakeItEasy این فرآیند را خودکار می‌کنند. Moq یکی از محبوب‌ترین فریم‌ورک‌ها برای C# است.

برای استفاده از Moq، ابتدا آن را در پروژه تست خود نصب کنید:

// Install-Package Moq

مثال: تست سرویس محصولات با وابستگی به Repository

فرض کنید یک سرویس مدیریت محصولات دارید که به یک Repository برای دسترسی به داده‌ها وابسته است:

// Project: MyApplication.Core
using System.Collections.Generic;

namespace MyApplication.Core
{
    public class Product
    {
        public int Id { get; set; }
        public string Name { get; set; }
        public decimal Price { get; set; }
    }

    public interface IProductRepository
    {
        Product GetProductById(int id);
        IEnumerable<Product> GetAllProducts();
        void AddProduct(Product product);
        void UpdateProduct(Product product);
        void DeleteProduct(int id);
    }

    public class ProductService
    {
        private readonly IProductRepository _productRepository;

        public ProductService(IProductRepository productRepository)
        {
            _productRepository = productRepository;
        }

        public Product GetProductDetails(int productId)
        {
            // ممکن است منطق کسب و کار اضافی اینجا وجود داشته باشد
            return _productRepository.GetProductById(productId);
        }

        public decimal CalculateTotalPrice(IEnumerable<int> productIds)
        {
            decimal total = 0;
            foreach (var id in productIds)
            {
                var product = _productRepository.GetProductById(id);
                if (product != null)
                {
                    total += product.Price;
                }
            }
            return total;
        }

        public bool AddProduct(Product product)
        {
            if (string.IsNullOrWhiteSpace(product.Name) || product.Price <= 0)
            {
                return false;
            }
            _productRepository.AddProduct(product);
            return true;
        }
    }
}

اکنون تست واحد برای `ProductService` با استفاده از Moq برای `IProductRepository`:

// Project: MyApplication.Core.Tests (NUnit example, but concept is same for XUnit)
using NUnit.Framework;
using Moq; // برای استفاده از Moq
using MyApplication.Core;
using System.Collections.Generic;
using System.Linq;

namespace MyApplication.Core.Tests
{
    [TestFixture]
    public class ProductServiceTests
    {
        private ProductService _productService;
        private Mock<IProductRepository> _mockProductRepository; // ماک از اینترفیس

        [SetUp]
        public void Setup()
        {
            // Arrange: ایجاد یک ماک از IProductRepository
            _mockProductRepository = new Mock<IProductRepository>();

            // Arrange: مقداردهی اولیه سرویس با ماک
            _productService = new ProductService(_mockProductRepository.Object);
        }

        [Test]
        public void GetProductDetails_ProductExists_ReturnsProduct()
        {
            // Arrange
            var expectedProduct = new Product { Id = 1, Name = "Laptop", Price = 1200m };

            // تنظیم رفتار ماک: وقتی GetProductById با ID 1 فراخوانی شود، expectedProduct را برگردان
            _mockProductRepository.Setup(repo => repo.GetProductById(1))
                                  .Returns(expectedProduct);

            // Act
            var actualProduct = _productService.GetProductDetails(1);

            // Assert
            Assert.IsNotNull(actualProduct);
            Assert.AreEqual(expectedProduct.Id, actualProduct.Id);
            Assert.AreEqual(expectedProduct.Name, actualProduct.Name);
            Assert.AreEqual(expectedProduct.Price, actualProduct.Price);

            // Assert: بررسی اینکه متد GetProductById دقیقاً یک بار فراخوانی شده است
            _mockProductRepository.Verify(repo => repo.GetProductById(1), Times.Once);
        }

        [Test]
        public void GetProductDetails_ProductDoesNotExist_ReturnsNull()
        {
            // Arrange
            // تنظیم رفتار ماک: وقتی GetProductById با ID 999 فراخوانی شود، null برگردان
            _mockProductRepository.Setup(repo => repo.GetProductById(999))
                                  .Returns((Product)null); // یا Returns(null)

            // Act
            var actualProduct = _productService.GetProductDetails(999);

            // Assert
            Assert.IsNull(actualProduct);
            _mockProductRepository.Verify(repo => repo.GetProductById(999), Times.Once);
        }

        [Test]
        public void CalculateTotalPrice_ValidProducts_ReturnsCorrectTotal()
        {
            // Arrange
            var product1 = new Product { Id = 1, Name = "Laptop", Price = 1000m };
            var product2 = new Product { Id = 2, Name = "Mouse", Price = 25m };
            var product3 = new Product { Id = 3, Name = "Keyboard", Price = 75m };

            _mockProductRepository.Setup(repo => repo.GetProductById(1)).Returns(product1);
            _mockProductRepository.Setup(repo => repo.GetProductById(2)).Returns(product2);
            _mockProductRepository.Setup(repo => repo.GetProductById(3)).Returns(product3);

            var productIds = new List<int> { 1, 2, 3 };
            decimal expectedTotal = 1100m; // 1000 + 25 + 75

            // Act
            decimal actualTotal = _productService.CalculateTotalPrice(productIds);

            // Assert
            Assert.AreEqual(expectedTotal, actualTotal);

            // Verify: بررسی که GetProductById برای هر ID دقیقا یک بار فراخوانی شده است
            _mockProductRepository.Verify(repo => repo.GetProductById(It.IsAny<int>()), Times.Exactly(productIds.Count));
        }

        [Test]
        public void AddProduct_ValidProduct_ReturnsTrueAndAddsProduct()
        {
            // Arrange
            var newProduct = new Product { Name = "Monitor", Price = 300m };

            // Setup: برای متدهای void، باید با Callback یا VerifyOnAllCalls
            _mockProductRepository.Setup(repo => repo.AddProduct(It.IsAny<Product>())); // برای متد void

            // Act
            bool result = _productService.AddProduct(newProduct);

            // Assert
            Assert.IsTrue(result);
            // Verify: بررسی که متد AddProduct با محصول صحیح فراخوانی شده است
            _mockProductRepository.Verify(repo => repo.AddProduct(
                It.Is<Product>(p => p.Name == newProduct.Name && p.Price == newProduct.Price)), Times.Once);
        }

        [Test]
        public void AddProduct_InvalidProduct_ReturnsFalseAndDoesNotAddProduct()
        {
            // Arrange: محصول با نام خالی
            var invalidProduct = new Product { Name = "", Price = 100m };

            // Act
            bool result = _productService.AddProduct(invalidProduct);

            // Assert
            Assert.IsFalse(result);
            // Verify: بررسی که متد AddProduct هرگز فراخوانی نشده است
            _mockProductRepository.Verify(repo => repo.AddProduct(It.IsAny<Product>()), Times.Never);
        }
    }
}

در این مثال، `_mockProductRepository.Setup(...)` رفتار مورد انتظار Repository را تعریف می‌کند، و `_mockProductRepository.Verify(...)` بررسی می‌کند که آیا این رفتار (فراخوانی متدها) به درستی در حین اجرای کد سرویس اتفاق افتاده است یا خیر.

بهترین روش‌ها و الگوهای تست واحد

نوشتن تست واحد تنها نیمی از ماجراست؛ نوشتن تست‌های واحد خوب و مؤثر هنر دیگری است. در اینجا برخی از بهترین روش‌ها و الگوها آورده شده است:

۱. تست نامگذاری‌های واضح و توصیفی

نام تست شما باید به وضوح مشخص کند که چه چیزی را تست می‌کند، در چه شرایطی، و چه انتظاری از آن دارید. از الگوی `MethodName_StateUnderTest_ExpectedBehavior` استفاده کنید. مثلاً `Add_TwoPositiveNumbers_ReturnsCorrectSum`.

۲. هر تست، یک سناریو

یک تست واحد باید فقط یک دلیل برای شکست داشته باشد. هر تست باید یک جنبه خاص از رفتار یک واحد را در یک سناریو خاص پوشش دهد. این کار اشکال‌زدایی را بسیار آسان‌تر می‌کند.

۳. تست‌های کوچک و با تمرکز بالا

تست‌ها باید کوچک باشند و فقط بر روی واحد کد تحت آزمایش تمرکز کنند. از فراخوانی‌های پیچیده یا وابستگی‌های زیاد در تست‌ها خودداری کنید.

۴. تست‌های خود-مستند

کد تست شما باید آنقدر واضح باشد که بتواند به عنوان مستندات برای کد اصلی عمل کند. استفاده از الگوی AAA و نامگذاری‌های واضح به این هدف کمک می‌کند.

۵. عدم تست کردن پیاده‌سازی داخلی

تست‌ها باید رفتار عمومی (public) یک واحد را آزمایش کنند، نه جزئیات پیاده‌سازی داخلی (private methods) آن را. تست کردن پیاده‌سازی داخلی باعث شکنندگی تست‌ها در هنگام بازسازی کد می‌شود.

۶. عدم تست کردن کد فریم‌ورک

شما نیازی به نوشتن تست برای کلاس‌ها یا متدهایی که بخشی از فریم‌ورک‌های استاندارد (مانند .NET BCL، ASP.NET Core) هستند، ندارید. فرض بر این است که این فریم‌ورک‌ها توسط توسعه‌دهندگان خودشان به خوبی تست شده‌اند.

۷. تست‌های سریع

همانطور که در اصول F.I.R.S.T ذکر شد، تست‌ها باید سریع باشند. اگر تست‌های شما کند می‌شوند، به فکر استفاده از Test Doubles یا Refactoring کد اصلی برای کاهش وابستگی‌ها باشید.

۸. حفظ قابلیت نگهداری تست‌ها

تست‌ها هم مانند کد تولیدی نیاز به بازسازی و نگهداری دارند. وقتی کد اصلی را بازسازی می‌کنید، تست‌های مربوطه را نیز بررسی و در صورت لزوم بازسازی کنید.

۹. پوشش کد (Code Coverage)

پوشش کد (که با ابزارهایی مانند Coverlet یا Fine Code Coverage قابل اندازه‌گیری است) درصدی از کدهای شما را نشان می‌دهد که توسط تست‌ها اجرا شده‌اند. هرچند پوشش ۱۰۰٪ همیشه به معنای کیفیت ۱۰۰٪ نیست، اما یک معیار مفید برای اطمینان از پوشش مناسب تست‌ها است. هدف، پوشش بالا در منطق کسب‌وکار حیاتی است.

۱۰. توسعه مبتنی بر تست (Test-Driven Development - TDD)

در TDD، چرخه توسعه شامل سه مرحله تکراری است:

1. Red (قرمز): ابتدا یک تست شکست‌خورده برای یک ویژگی جدید یا یک باگ می‌نویسید.
2. Green (سبز): کمترین کد ممکن را برای پاس کردن تست می‌نویسید.
3. Refactor (بازسازی): کد تولیدی و تست‌ها را برای بهبود کیفیت، خوانایی و کارایی بازسازی می‌کنید، بدون اینکه تست‌ها را بشکنید.

TDD به بهبود طراحی کد، کاهش باگ‌ها و افزایش اعتماد به نفس در کد کمک می‌کند.

چالش‌ها و راهکارها در تست واحد

اگرچه تست واحد مزایای زیادی دارد، اما ممکن است با چالش‌هایی نیز همراه باشد. درک این چالش‌ها و دانستن راهکارهای آن‌ها به شما کمک می‌کند تا فرآیند تست را هموارتر کنید.

۱. تست کردن کد قدیمی (Legacy Code)

چالش: کدهای قدیمی معمولاً با وابستگی‌های زیاد، کوپلینگ بالا و بدون در نظر گرفتن قابلیت تست‌پذیری نوشته شده‌اند. نوشتن تست واحد برای این کدها بسیار دشوار یا حتی غیرممکن است.

راهکار:

• استفاده از Characterization Tests (Golden Master Tests): این تست‌ها رفتار فعلی کد قدیمی را "ثبت" می‌کنند. بدون تغییر کد، آن را اجرا کرده و خروجی‌های آن را به عنوان مرجع ثبت می‌کنید. سپس، هنگام بازسازی، اگر تغییرات شما رفتار خارجی کد را تغییر داد، تست شکست می‌خورد.
• Small Refactoring: با انجام تغییرات کوچک و ایمن (مانند استخراج اینترفیس‌ها، تزریق وابستگی‌ها) به تدریج کد را تست‌پذیر کنید.
• استفاده از ابزارهای Legacy Code: فریم‌ورک‌هایی مانند Typemock Isolator می‌توانند به ماک کردن وابستگی‌های سخت (مانند متدهای استاتیک یا کلاس‌های Sealed) کمک کنند.

۲. وابستگی‌های سخت و مدیریت آن‌ها

چالش: کلاسی که می‌خواهید تست کنید، به کلاس‌های دیگری وابسته است که عملیات‌های پرهزینه، کند یا غیرقابل کنترل (مانند دسترسی به پایگاه داده، فراخوانی سرویس‌های خارجی، I/O) را انجام می‌دهند.

راهکار:

• اصل Inversion of Control (IoC) / Dependency Injection (DI): وابستگی‌ها را از طریق سازنده یا متدهای setter تزریق کنید، نه اینکه آن‌ها را درون کلاس نمونه‌سازی کنید. این کار ماک کردن یا استاب کردن وابستگی‌ها را آسان‌تر می‌کند.
• استفاده از Test Doubles: همانطور که بحث شد، از Moq یا سایر فریم‌ورک‌های Mocking برای جایگزینی وابستگی‌های واقعی با نسخه‌های کنترل شده استفاده کنید.
• رعایت SOLID Principles: به خصوص Single Responsibility Principle (SRP) و Dependency Inversion Principle (DIP) به تولید کدی با وابستگی‌های کمتر و تست‌پذیرتر کمک می‌کنند.

۳. بیش از حد ماک کردن (Over-Mocking)

چالش: گاهی اوقات توسعه‌دهندگان بیش از حد ماک می‌کنند، به طوری که هر وابستگی را ماک کرده و در نتیجه تست‌ها بسیار شکننده می‌شوند. تغییر کوچک در پیاده‌سازی یک وابستگی، ممکن است باعث شکست تعداد زیادی از تست‌ها شود.

راهکار:

• تست تعاملات، نه پیاده‌سازی: ماک‌ها را برای تست کردن "تعاملات" با وابستگی‌های مهم (مثلاً آیا متد ذخیره‌سازی داده فراخوانی شد؟) استفاده کنید، نه برای تقلید دقیق هر جنبه از رفتار وابستگی.
• استفاده از استاب‌ها برای داده: اگر یک وابستگی فقط برای فراهم کردن داده استفاده می‌شود و رفتار خاصی ندارد، از استاب (Stub) به جای ماک (Mock) استفاده کنید.
• کاهش تعداد وابستگی‌ها: اگر یک کلاس وابستگی‌های زیادی دارد، ممکن است نشانه‌ای از نقض SRP باشد. کلاس را بازسازی کنید تا وظایفش متمرکزتر شوند.

۴. تست‌های کند

چالش: مجموعه تست‌های واحد بزرگ می‌شود و زمان اجرای آن‌ها طولانی می‌شود، که منجر به عدم تمایل توسعه‌دهندگان به اجرای مکرر تست‌ها می‌شود.

راهکار:

• تست‌های ایزوله و سریع: مطمئن شوید که هر تست مستقل است و به منابع خارجی کند (مانند دیسک، شبکه، پایگاه داده) دسترسی ندارد.
• اجرای موازی: از قابلیت‌های اجرای موازی فریم‌ورک‌های تست (مانند XUnit یا NUnit 3+) برای اجرای همزمان تست‌ها استفاده کنید.
• سیستم CI/CD: تست‌های خود را به صورت خودکار در سیستم یکپارچه‌سازی پیوسته (CI) اجرا کنید تا حتی اگر توسعه‌دهندگان به صورت دستی آن‌ها را اجرا نکردند، کیفیت کد حفظ شود.

۵. حفظ تست‌ها و تست‌های flaky (ناپایدار)

چالش: تست‌ها ممکن است ناپایدار شوند (گاهی قبول، گاهی رد) یا نگهداری آن‌ها دشوار شود، به خصوص اگر کد تغییر کند.

راهکار:

• تست‌های قابل تکرار: اطمینان حاصل کنید که تست‌ها به عواملی مانند زمان، ترتیب اجرا، یا محیط خاص وابسته نیستند.
• نامگذاری‌های دقیق: نامگذاری واضح تست‌ها کمک می‌کند تا هنگام شکست، دلیل آن به سرعت مشخص شود.
• Refactoring تست‌ها: تست‌ها را نیز مانند کد اصلی بازسازی کنید تا خوانایی و قابلیت نگهداری آن‌ها افزایش یابد.
• بررسی دقیق دلیل شکست: هنگام شکست یک تست، به جای صرفاً نادیده گرفتن آن، علت ریشه‌ای را بررسی و رفع کنید.

نتیجه‌گیری

تست واحد، بیش از آنکه یک فعالیت اضافی باشد، یک جزء حیاتی و جدایی‌ناپذیر از فرآیند توسعه نرم‌افزار مدرن است. با درک اصول F.I.R.S.T و بهره‌گیری از فریم‌ورک‌های قدرتمندی مانند NUnit و XUnit، توسعه‌دهندگان C# می‌توانند کدی با کیفیت بالاتر، باگ‌های کمتر و قابلیت نگهداری آسان‌تر تولید کنند.

انتخاب بین NUnit و XUnit اغلب به ترجیحات تیمی و نیازهای پروژه بستگی دارد؛ هر دو ابزارهای عالی برای رسیدن به هدف مشترک (تولید نرم‌افزار پایدار) هستند. استفاده از Test Doubles و فریم‌ورک‌هایی مانند Moq نیز به شما امکان می‌دهد تا حتی کدهای با وابستگی‌های پیچیده را به صورت ایزوله و مؤثر آزمایش کنید.

پذیرش تست واحد و رویکردهای مرتبط مانند TDD، نه تنها به شما در شناسایی زودهنگام مشکلات کمک می‌کند، بلکه به عنوان یک مستندات زنده برای کد شما عمل کرده و اعتماد به نفس شما را در ایجاد تغییرات بزرگ در سیستم افزایش می‌دهد. با سرمایه‌گذاری زمان در نوشتن تست‌های واحد مؤثر، در بلندمدت زمان و هزینه‌های بسیار بیشتری را صرفه‌جویی خواهید کرد.