‫بهبود تست‌نویسی در توسعه نرم‌افزار با تمرکز بر اجتناب از Assertion Roulette

public void TestInvoice_AddLineItem()
{
    var invoice = new Invoice();
    var product = new Product(1, "Widget", 19.99m);
    invoice.AddItemQuantity(product, 5);
    var lineItems = invoice.GetLineItems();
    var actual = (LineItem)lineItems[0];
    Assert.AreEqual(invoice, actual.GetInvoice());
    Assert.AreEqual(product, actual.GetProduct());
    Assert.AreEqual(5, actual.GetQuantity());
}

1. کاهش خوانایی تست: بدون پیام‌های توضیحی، توسعه‌دهندگان نمی‌توانند به سرعت متوجه شوند که تست چه چیزی را بررسی می‌کند. این موضوع در تیم‌های بزرگ که افراد مختلف کد را بررسی می‌کنند، اهمیت بیشتری دارد.
2. دشواری در عیب‌یابی: در محیط‌های یکپارچه‌سازی مداوم (Continuous Integration) مانند Azure DevOps، وقتی تست‌ها به صورت خودکار اجرا می‌شوند، گزارش شکست باید اطلاعات کافی برای رفع سریع مشکل ارائه دهد.
3. افزایش هزینه نگهداری: تست‌هایی که به سختی قابل فهم هستند، هزینه نگهداری پروژه را بالا می‌برند، زیرا توسعه‌دهندگان باید زمان بیشتری برای تحلیل و اصلاح آن‌ها صرف کنند.

public void TestInvoice_AddLineItem()
{
    var invoice = new Invoice();
    var product = new Product(1, "Widget", 19.99m);
    invoice.AddItemQuantity(product, 5);
    var lineItems = invoice.GetLineItems();
    var actual = (LineItem)lineItems[0];
    Assert.AreEqual(invoice, actual.GetInvoice(), "فاکتور خط آیتم باید با فاکتور اصلی یکسان باشد");
    Assert.AreEqual(product, actual.GetProduct(), "محصول خط آیتم باید با محصول اصلی یکسان باشد");
    Assert.AreEqual(5, actual.GetQuantity(), "تعداد باید 5 باشد");
}

public static class InvoiceAssertions
{
    public static void AssertLineItem(LineItem actual, Invoice expectedInvoice, Product expectedProduct, int expectedQuantity)
    {
        Assert.AreEqual(expectedInvoice, actual.GetInvoice(), "فاکتور خط آیتم باید با فاکتور اصلی یکسان باشد");
        Assert.AreEqual(expectedProduct, actual.GetProduct(), "محصول خط آیتم باید با محصول اصلی یکسان باشد");
        Assert.AreEqual(expectedQuantity, actual.GetQuantity(), $"تعداد باید {expectedQuantity} باشد");
    }
}

public void TestInvoice_AddLineItem()
{
    var invoice = new Invoice();
    var product = new Product(1, "Widget", 19.99m);
    invoice.AddItemQuantity(product, 5);
    var lineItems = invoice.GetLineItems();
    var actual = (LineItem)lineItems[0];
    InvoiceAssertions.AssertLineItem(actual, invoice, product, 5);
}

public void TestInvoice_AddLineItem_InvoiceMatches()
{
    var invoice = new Invoice();
    var product = new Product(1, "Widget", 19.99m);
    invoice.AddItemQuantity(product, 5);
    var lineItems = invoice.GetLineItems();
    var actual = (LineItem)lineItems[0];
    Assert.AreEqual(invoice, actual.GetInvoice(), "فاکتور خط آیتم باید با فاکتور اصلی یکسان باشد");
}

public void TestInvoice_AddLineItem_ProductMatches()
{
    var invoice = new Invoice();
    var product = new Product(1, "Widget", 19.99m);
    invoice.AddItemQuantity(product, 5);
    var lineItems = invoice.GetLineItems();
    var actual = (LineItem)lineItems[0];
    Assert.AreEqual(product, actual.GetProduct(), "محصول خط آیتم باید با محصول اصلی یکسان باشد");
}

public void TestInvoice_AddLineItem_QuantityMatches()
{
    var invoice = new Invoice();
    var product = new Product(1, "Widget", 19.99m);
    invoice.AddItemQuantity(product, 5);
    var lineItems = invoice.GetLineItems();
    var actual = (LineItem)lineItems[0];
    Assert.AreEqual(5, actual.GetQuantity(), "تعداد باید 5 باشد");
}

• استفاده از Test Data Builders: برای کاهش پیچیدگی تنظیم فیکسچرها (Fixtures)، از الگوی Test Data Builder استفاده کنید. این الگو به شما امکان می‌دهد داده‌های تست را به صورت خوانا و قابل تنظیم ایجاد کنید.
• اجتناب از تست‌های بیش از حد مشتاق (Eager Tests): تست‌هایی که چندین رفتار را همزمان بررسی می‌کنند، می‌توانند به Assertion Roulette منجر شوند. هر تست را روی یک رفتار خاص متمرکز کنید.
• یکپارچه‌سازی با CI/CD: در سیستم‌های یکپارچه‌سازی مداوم مانند Azure DevOps یا GitHub Actions، اطمینان حاصل کنید که گزارش‌های تست شامل جزئیات کافی هستند. این کار از طریق تنظیمات مناسب امکان‌پذیر است.