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

در ابتدا ممکن است این مهفوم کمی گنگ باشد. در واقع ما در مقاله آشنایی با Unit Test اهمیت تست پس از نوشتن کد را مورد بررسی قرار داده‌ایم. حال اینکه این مرحله پیش از نوشتن یک کد اتفاق می‌افتد. بنابراین تست در مرحله پیش از نوشتن کد ممکن است کمی دور از ذهن باشد. وقتی صحبت از TDD به میان می‌آید, منظور این است که در ابتدا تست های مد نظر را بنویسیم و سپس برای آن تست ها کد های مورد نیاز را ایجاد می‌کنیم.

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

مفهوم رنگ ها در Testing

تست های زرد

تست های زرد و یا Yellow Box Testing به تست هایی اطلاق می‌شود که برای بررسی پیام های هشدار استفاده می‌شود. این نام متناسب با کاربرد رنگ زرد برای نشان دادن هشدار انتخاب شده است. برای مثال وقتی شما یک مرحله از تست را برای نمایش هشدار می‌نویسید, شما یک تست زرد را پیاده سازی کرده‌اید.

تست های سبز

تست های سبز و یا Green Box Testing به تست هایی اطلاق می‌شود که رفتار یک بخش را در تعامل با بخش های دیگر مشخص می‌کند. برای مثال Integration Test ها در این دسته قرار می‌گیرند. Integration Test ها, تست هایی هستند که چند بخش را در یک سیر از اتفاقات بررسی می‌کند. اگر تمام این بخش ها در کنار هم, خروجی مد نظر را ایجاد کنند, این مرحله با موفقیت به پایان می‌رسد. فرض کنید یک فرم ورود داریم و می‌خواهیم مراحل ورود اطلاعات و احراز هویت کاربر را با استفاده از پایگاه داده را چک کنیم. مرحله تست اطلاعات ورودی و تست دریافت اطلاعات از پایگاه داده, می‌توانند تست های مستقلی باشند. اما اگر بخواهیم ارتباط این تست ها را در کنار یکدیگر بررسی کنیم, این تست در حوزه تست های سبز قرار می‌گیرد.

تست های قرمز

تست های قرمز و یا Red Box Testing به تست هایی اطلاق می‌شود که برای پذیرش یک بخش مورد استفاده قرار می‌گیرد. اگر تست ها در این مرحله با شکست مواجه شوند, از سیستم کنار گذاشته می‌شوند و بلا استفاده هستند.

تمام تست های TDD در حوزه تست های قرمز قرار دارند. اگر یک تست TDD با شکست روبرو شود از پروژه کنار گذاشته می‌شود. بنابراین تمام تست ها در این حوزه تا وقتی که با موفقیت انجام نشوند, در پروژه استفاده نمی‌شوند. هر بخش پس از گذراندن این تست ها پیاده سازی می‌شوند. سپس مرحله پیاده سازی تا وقتی که تست های آن سبز نشوند ادامه پیدا می‌کنند.

یک TDD ساده

فرض کنید می‌خواهیم یک کلاس ایجاد کنیم که با استفاده از یک متد دو عدد را جمع کنیم. بنابراین در مرحله اول باید تست های مورد نیاز را بنویسیم:

public class CalculatorTest {

    private Calculator calculator;

    @Before
    public void setup() {
        calculator = new Calculator();
    }

    @Test
    public void addMethodTest() {
        int expected = 5;
        int number1 = 2;
        int number2 = 3;

        assertEquals(expected, calculator.add(number1, number2));
    }

}

این کلاس, برای تست نوشته شده است. حال کلاس Calculator را بررسی می‌کنیم:

public class Calculator {
}

همانطور که مشاهده می‌کنید, متد add در کلاس Calculator وجود ندارد. اما ما یک متد تست ایجاد کرده‌ایم و در خواست مساله را در آن پیاده سازی کرده‌ایم. حال متناسب با خواست مساله باید کد متد add را پیاده سازی کنیم:

public class Calculator {
    
    public int add(int a, int b) {
        return a + b;    
    }
}

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

در این مقاله سعی بر این شد تا با مفهوم TDD و شیوه پیاده سازی آن آشنا شویم.

با ما همراه باشید.