توسعه آزمون‌محور (TDD)

مشکل: تستی که هیچ وقت نوشته نمی‌شود

تیم فروش فروشگاه ما یک قانون جدید می‌خواهد: «هزینه ارسال ۵۰ هزار تومان است. ولی سفارش ۵۰۰ هزار تومانی یا بیشتر، ارسال رایگان دارد.»

روش معمول این است:

1. کد کامل را یک‌جا می‌نویسیم. گاهی همراه چند حالت اضافه که «شاید بعداً لازم شود».
2. دستی امتحان می‌کنیم. کار می‌کند. خوشحالیم.
3. می‌گوییم تست را بعداً می‌نویسیم. ولی کار بعدی می‌رسد و تست هیچ وقت نوشته نمی‌شود.
4. اگر هم بنویسیم، سخت است. چون کلاس از اول برای تست شدن طراحی نشده است. مثلاً مستقیم به دیتابیس یا ساعت سیستم وصل است.

ایده TDD: اول تست، بعد کد

در توسعه آزمون‌محور (Test-Driven Development) ترتیب را برعکس می‌کنیم. هیچ خط کد اصلی نمی‌نویسیم، مگر برای سبز کردن یک تست قرمز. کار در یک چرخه کوتاه و تکراری انجام می‌شود:

1. قرمز (Red). یک تست کوچک برای یک رفتار جدید بنویس. آن را اجرا کن و ببین که شکست می‌خورد. اگر سبز شد، یا رفتار از قبل وجود داشت یا تست اشتباه است.
2. سبز (Green). ساده‌ترین کدی را بنویس که تست را سبز کند. در این قدم زیبایی کد مهم نیست. فقط سبز شدن مهم است.
3. بازسازی (Refactor). حالا که همه تست‌ها سبزند، کد را تمیز کن. اسم‌ها را بهتر کن و تکرار را حذف کن. بعد از هر تغییر کوچک، تست‌ها را اجرا کن.

مثال زنده

قانون هزینه ارسال را قدم به قدم با TDD بساز. به رنگ هر قدم و به تغییر کد دقت کن:

به قدم دوم دقت کن. کد «همیشه ۵۰ هزار برگردان» عجیب به نظر می‌رسد. ولی این کار عمدی است و دو دلیل دارد:

1. قدم کوچک می‌ماند. اگر چیزی خراب شد، می‌دانیم دقیقاً کدام تغییر آن را خراب کرد.
2. تست بعدی کد را مجبور به کلی شدن می‌کند. کنت بک (Kent Beck) به این کار Triangulation می‌گوید. یعنی با دو یا چند مثال، کد را به سمت قانون کلی هل می‌دهیم.

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

کد نهایی

بعد از چند دور، تست‌ها و کد این شکل را دارند:

public class ShippingCostTests
{
    [Theory]
    [InlineData(200_000, false, 50_000)]
    [InlineData(499_999, false, 50_000)]
    [InlineData(500_000, false, 0)]
    [InlineData(200_000, true, 0)]
    public void Shipping_cost_follows_the_rules(int total, bool isVip, int expected)
    {
        var cost = ShippingCost.For(total, isVip);

        Assert.Equal(expected, cost);
    }
}

public static class ShippingCost
{
    private const decimal FreeFrom = 500_000m;
    private const decimal Standard = 50_000m;

    public static decimal For(decimal orderTotal, bool isVip) =>
        isVip || orderTotal >= FreeFrom ? 0m : Standard;
}

به دو ردیف ۴۹۹٬۹۹۹ و ۵۰۰٬۰۰۰ دقت کن. این‌ها مرز قانون هستند. نوشتن تست قبل از کد، ما را مجبور می‌کند درباره همین مرزها فکر کنیم و از تیم فروش بپرسیم: «۵۰۰ هزار دقیقاً رایگان است یا از آن به بعد؟»

چرا TDD کمک می‌کند؟

1. طراحی بهتر. وقتی اول تست را می‌نویسی، اول از دید استفاده‌کننده به کلاس نگاه می‌کنی. کلاسی که تستش سخت است، معمولاً طراحی بدی دارد. این را خیلی زود می‌فهمی.
2. فقط کد لازم. هر خط کد به خاطر یک تست نوشته شده است. کد اضافه «برای روز مبادا» کمتر نوشته می‌شود.
3. شبکه ایمنی. هر رفتار یک تست دارد. پس بازسازی بعدی ترسناک نیست.
4. مستندات زنده. اسم تست‌ها قانون‌های کسب‌وکار را توضیح می‌دهند و همیشه با کد هماهنگ هستند.
5. قدم‌های کوچک. همیشه چند دقیقه با یک حالت سالم فاصله داری. اگر گم شدی، تغییر آخر را برمی‌گردانی.

دو سبک: از داخل به بیرون، از بیرون به داخل

قانون‌های مهم

1. هر بار فقط یک تست قرمز. چند تست قرمز با هم یعنی قدم خیلی بزرگ است.
2. قدم بازسازی را جا نینداز. بدون آن، TDD فقط کد شلوغ با تست تولید می‌کند.
3. در قدم سبز، کد اضافه ننویس. اگر رفتار جدیدی به ذهنت رسید، آن را در یک لیست بنویس. بعداً با یک تست جدید سراغش برو.
4. رفتار را تست کن، نه پیاده‌سازی را. وگرنه قدم بازسازی تست‌ها را می‌شکند و TDD دردناک می‌شود.
5. تست‌ها سریع باشند. چرخه TDD چند دقیقه است. اگر اجرای تست‌ها یک دقیقه طول بکشد، چرخه از بین می‌رود.

اشتباه‌های رایج

چه وقت TDD؟