Testing

#اختار الاختبار حسب المخاطرة: Pyramid و TrophyChoose tests by risk: pyramid and trophy

المطلوب من الـ tests إنك تكتشف الغلط قبل المستخدم، وتعرف سببه بسرعة. الـ unit test بيختبر سلوك صغير من غير infrastructure، والـ integration بيختبر أجزاء متوصلة ببعض، والـ E2E بيمشي رحلة المستخدم في النظام كله.

دي إرشادات مش نسب إلزامية. اختبر خصم الفاتورة بوحدات سريعة، وتخزين الطلب والدفع بـ integration، وسيب E2E لرحلات زي checkout. ماتكررش كل حالات الحساب في كل مستوى.

#Unit test واضح: AAA و FIRST و xUnit v3Readable unit tests: AAA, FIRST and xUnit v3

الـ test المفيد بيشرح قاعدة واحدة وبيفشل برسالة واضحة. AAA معناها Arrange للمدخلات، و Act لاستدعاء السلوك، و Assert للنتيجة. FIRST: Fast، و Independent، و Repeatable، و Self-validating، و Timely. المثال كامل جوه test project بيستخدم xUnit v3، مع using Xunit;.

public static class ShippingPolicy
{
    public static int Fee(int total) => total >= 1000 ? 0 : 50;
}

public sealed class ShippingTests
{
    [Fact] // (1)
    public void Fee_AtFreeShippingThreshold_IsZero()
    {
        var total = 1000;                  // Arrange
        var fee = ShippingPolicy.Fee(total); // Act
        Assert.Equal(0, fee);              // Assert (2)
    }

    [Theory] // (3)
    [InlineData(999, 50)]
    [InlineData(1000, 0)]
    [InlineData(1001, 0)]
    public void Fee_UsesThreshold(int total, int expected) =>
        Assert.Equal(expected, ShippingPolicy.Fee(total));
}

ممكن تعمل كذا assertion لنفس النتيجة المنطقية. ماتختبرش getters بسيطة لمجرد رفع coverage، وماتخليش test واحد يجرّب رحلة طويلة من سلوكيات مستقلة. راجع دليل xUnit v3 لإعداد الـ runner المناسب.

#Fixtures: مشاركة التكلفة من غير مشاركة المشاكلFixtures: share setup cost without sharing failures

xUnit بيعمل instance جديد من test class لكل test case. الـ constructor مناسب لتحضير خفيف، و IDisposable أو IAsyncDisposable للتنضيف. الـ fixture بيشارك resource غالي، لكنه مش بيعمل reset للداتا تلقائي.

المثال محتاج using Xunit;، وبيوضح collection واحدة بتشارك counter للتوضيح؛ في التطبيق الحقيقي شارك database fixture مع isolation للداتا.

public sealed class SharedCounter
{
    public int Value { get; set; }
}

[CollectionDefinition("orders")]
public sealed class OrdersCollection : ICollectionFixture<SharedCounter> { } // (1)

[Collection("orders")]
public sealed class OrderTests(SharedCounter counter) // (2)
{
    [Fact]
    public void Counter_CanBeReset()
    {
        counter.Value = 0;
        Assert.Equal(0, counter.Value);
    }
}

#Assertions و Test doubles: اختبر العقدAssertions and test doubles: test the contract

الـ assertion لازم يمسك الغلط المقصود: قيمة total، أو error محدد، أو عدم تكرار charge. الـ dummy parameter مش مستخدم؛ الـ stub بيرجّع رد جاهز؛ الـ fake تنفيذ مبسط شغال؛ الـ mock بيتحقق من interaction متوقع؛ والـ spy بيسجل calls علشان تفحصها بعدين. دي أدوار، ومكتبة واحدة ممكن تعمل أكتر من دور.

المثال مستقل في xUnit project مع packages بتاعة NSubstitute و Moq. بيعرض نفس إعداد الـ stub بالطريقتين؛ اختار واحدة في الـ test الفعلي.

using Moq;
using NSubstitute;
using Xunit;

public interface IPaymentGateway
{
    bool Charge(decimal amount);
}

public sealed class Checkout(IPaymentGateway gateway)
{
    public bool TryPay(decimal amount)
    {
        ArgumentOutOfRangeException.ThrowIfNegativeOrZero(amount);
        return gateway.Charge(amount);
    }
}

public sealed class GatewayTests
{
    [Fact]
    public void TryPay_WhenGatewayDeclines_ReturnsFalse()
    {
        var sub = Substitute.For<IPaymentGateway>();
        sub.Charge(100m).Returns(false); // (1)
        Assert.False(new Checkout(sub).TryPay(100m));
        sub.Received(1).Charge(100m); // (2)

        var mock = new Mock<IPaymentGateway>();
        mock.Setup(x => x.Charge(100m)).Returns(false); // (3)
        Assert.False(new Checkout(mock.Object).TryPay(100m));
        mock.Verify(x => x.Charge(100m), Times.Once());
    }
}

استخدم domain objects حقيقية، وقلل verification على تفاصيل داخلية بتتغير مع refactoring. Assertions المدمجة كفاية؛ Shouldly و AwesomeAssertions بيوفروا صياغة مقروءة. FluentAssertions v8 بقى بترخيص تجاري للاستخدام التجاري؛ راجع الترخيص قبل الترقية، زي أي dependency.

#اختبار الوقت من غير Thread.SleepTest time without Thread.Sleep

اختبار انتهاء حجز مش المفروض يستنى عشر دقايق حقيقية. حقن TimeProvider بيفصل قاعدة الوقت عن ساعة الجهاز. المثال محتاج xUnit، و package Microsoft.Extensions.TimeProvider.Testing.

using Microsoft.Extensions.Time.Testing;
using Xunit;

public sealed class Booking(TimeProvider clock, DateTimeOffset expiresAt)
{
    public bool IsExpired => clock.GetUtcNow() >= expiresAt; // (1)
}

public sealed class BookingTests
{
    [Fact]
    public void Booking_AtExpiry_IsExpired()
    {
        var start = new DateTimeOffset(2026, 1, 1, 0, 0, 0, TimeSpan.Zero);
        var clock = new FakeTimeProvider(start); // (2)
        var booking = new Booking(clock, start.AddMinutes(10));
        Assert.False(booking.IsExpired);
        clock.Advance(TimeSpan.FromMinutes(10)); // (3)
        Assert.True(booking.IsExpired);
    }
}

تقديم الساعة مش معناه إن كل background continuation خلصت. استنى إشارة اكتمال واضحة. ولقياس مدة، استخدم timestamp APIs بدل ساعة الحائط اللي ممكن تتعدل.

#Integration: الـ API مع database حقيقيةIntegration: an API with a real database

اختبار controller لوحده مش هيكشف DI ناقص أو query مش بتترجم. WebApplicationFactory بيشغل التطبيق بـ TestServer افتراضياً من غير network socket؛ Testcontainers بيدير database مؤقتة في Docker. المثال fragment لـ test project فيه xUnit v3، و Microsoft.AspNetCore.Mvc.Testing 10، و Testcontainers.PostgreSql، و reference للـ API. لازم الـ API يعرّف public partial class Program { }، ويقرأ connection string وقت تسجيل DbContext. نفترض endpoint /health بيرجع نجاح، و migrations بتتطبق بخطوة setup منفصلة قبل اختبار الداتا.

using Microsoft.AspNetCore.Hosting;
using Microsoft.AspNetCore.Mvc.Testing;
using Testcontainers.PostgreSql;
using Xunit;

public sealed class ApiFixture : IAsyncLifetime
{
    private readonly PostgreSqlContainer db = new PostgreSqlBuilder()
        .WithImage("postgres:17").Build();
    public WebApplicationFactory<Program> App { get; private set; } = null!;

    public async ValueTask InitializeAsync()
    {
        await db.StartAsync(); // (1)
        App = new WebApplicationFactory<Program>().WithWebHostBuilder(b =>
            b.UseSetting("ConnectionStrings:Default", db.GetConnectionString())); // (2)
    }

    public async ValueTask DisposeAsync()
    {
        if (App is not null) await App.DisposeAsync(); // (3)
        await db.DisposeAsync();
    }
}

public sealed class ApiTests(ApiFixture fixture) : IClassFixture<ApiFixture>
{
    [Fact]
    public async Task Health_ReturnsSuccess()
    {
        using var client = fixture.App.CreateClient(); // (4)
        using var response = await client.GetAsync("/health");
        response.EnsureSuccessStatusCode();
    }
}

استبدل payment boundary بـ fake، لكن خليك على auth الحقيقي في اختبارات الأمان. الـ TestServer مش بيختبر TLS ولا reverse proxy؛ دول محتاجين اختبار deployment. مثال Testcontainers الرسمي.

#Database isolation و ليه EF InMemory مش بديلDatabase isolation and why EF InMemory is insufficient

لو test ناجح لوحده وفاشل مع باقي الـ suite، فتّش على داتا مشتركة. database لكل مجموعة مع reset بين الحالات حل عملي. Respawn بيقرأ العلاقات ويمسح الداتا بترتيب مناسب؛ شغله بعد migrations واحتفظ بجدول migration history. المثال fragment بعد فتح Npgsql connection اسمها connection على database اختبار فقط، مع package Respawn.

var reset = await Respawn.Respawner.CreateAsync(connection, new()
{
    DbAdapter = Respawn.DbAdapter.Postgres,
    SchemasToInclude = ["public"],
    TablesToIgnore = [new Respawn.Graph.Table("__EFMigrationsHistory")]
}); // (1)

await reset.ResetAsync(connection); // (2)
// Seed only the data required by the next test.

transaction rollback مفيد بس لو كل الشغل مشارك فعلاً في نفس transaction؛ HTTP request غالباً بيفتح connection تانية. EF InMemory مش relational: مش بيختبر SQL translation ولا foreign keys ولا transactions الحقيقية. SQLite أحسن لبعض الحالات، لكن له dialect وسلوك مختلفين عن SQL Server و PostgreSQL. اختبر queries المهمة على نفس engine بتاع production. مقارنة EF الرسمية و Respawn.

#Contracts و Architecture testsContract and architecture tests

service ممكن يعدّي كل unit tests ويكسر consumer بتغيير اسم field. consumer-driven contract testing بيسجل الطلب والرد اللي consumer محتاجهم، و provider verification بيتأكد إن الـ provider الحقيقي ملتزم. Pact مثال؛ contract مش بديل لاختبار auth ولا رحلة business كاملة.

architecture tests بتمنع dependencies مخالفة للقرار المعماري. المثال كامل مع xUnit داخل test project بيعمل reference لـ domain assembly اسمها Store.Domain.

using System.Reflection;
using Xunit;

public sealed class DependencyTests
{
    [Fact]
    public void Domain_DoesNotReferenceEfCore()
    {
        var domain = Assembly.Load("Store.Domain"); // (1)
        var references = domain.GetReferencedAssemblies();
        Assert.DoesNotContain(references,
            a => a.Name?.StartsWith("Microsoft.EntityFrameworkCore") == true); // (2)
    }
}

snapshot tests مفيدة لشكل JSON ثابت، لكن لازم review للتغيير وتنضيف IDs والوقت المتغير. قبول snapshot جديد تلقائياً بيلغي قيمة الاختبار.

#TDD و BDD و Coverage و Mutation testingTDD, BDD, coverage and mutation testing

لما قاعدة الخصم مش واضحة، اكتب مثال متوقع الأول. TDD دورة قصيرة: Red، اتأكد الاختبار فشل للسبب الصح؛ Green، أقل تنفيذ صحيح؛ Refactor، حسّن التصميم والاختبارات خضرا. BDD بيبدأ بمحادثة وأمثلة مشتركة مع business، وممكن يصيغها Given و When و Then؛ مش مجرد tool أو syntax.

1. اكتب حالة total عند حد الشحن المجاني.
2. شغّلها قبل التنفيذ علشان تثبت إنها بتكشف السلوك الناقص.
3. نفّذ، وبعدين أضف حالة أقل من الحد، وحسّن الكود.

line coverage بيقول إيه اتنفذ، و branch coverage بيوضح الفروع اللي اتاخدت؛ ولا واحد بيقيس قوة assertions. Stryker.NET بيغيّر الكود عمداً، زي >= إلى >؛ اختبار الحد لازم يفشل ويقتل الـ mutant.

#Flaky tests و Load و ConcurrencyFlaky tests, load and concurrency

الـ flaky test بيغير نتيجته من غير تغيير مقصود في الكود. الأسباب الشائعة وقت حقيقي، و random seed مش مسجل، و shared state، و network، وترتيب تنفيذ مفترض. استخدم clock متحكم فيه، وبيانات مستقلة، و bounded polling لشرط واضح بدل sleep عشوائي. العزل المؤقت محتاج owner وموعد إصلاح؛ retry لوحده بيخبي المشكلة.

k6 بيكتب load scenarios بـ JavaScript، و NBomber بيسمح بتعريفها بـ .NET. حدد workload واقعي و arrival rate ومدة و warm-up، وراقب throughput و error rate و p95 و p99 مع CPU و DB waits. اختبر البيئة المخصصة؛ load test مش unit test للـ race.

1. لاختبار آخر قطعة: جهز stock = 1 في database حقيقية.
2. استخدم DbContext مستقل لكل مشتري، ونسق البداية بإشارة أو barrier مناسب.
3. نفذ المحاولتين، وتحقق إن نجاح واحد فقط، والمخزون مش سالب، والخاسر أخد نتيجة متوقعة.
4. كرر بجدولة مختلفة، وأضف اختبارات retry و idempotency. التكرار يزوّد الثقة لكنه مش إثبات لكل interleaving.