خانه > Agile, TDD, Unit Testing > آیا TDD در عمل امکان پذیر می باشد؟

آیا TDD در عمل امکان پذیر می باشد؟


آیا TDD در عمل امکان پذیر می باشد ؟ این سوالی بود که یکی از عزیزان از بنده پرسیده بود . ایشون فرموده بودند : «شما که می گید اول تست بنویسیم و بعد کد نویسی , مگر چنین چیزی ممکن است ؟ مگر برای کد نانوشته می شود تست نوشت؟ » و ایشون TDD را به یک افسانه تشبیه کرده بودند . من همین سوال را از شما می پرسم , آیا در عمل و یا اصطلاحا در Real World امکان دارد که TDD عملی شود ؟

در مقاله قبلی گفته شد که : TDD عبارتست از ترکیب TFD یا همان Test First Design و Refactor . به عبارت ساده تر یعنی ما اول قبل از اینکه شروع به کدنویسی بکنیم اول تست ها رو طراحی می کنیم و بعد کد نویسی می کنیم و بعد رفاکتور می کنیم . ادامه …

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

به نظر من راز موفقیت در User Story های خوب و کامل می باشد . اگر مقاله بنده در مورد اسکرام با عنوان اسکرام ساده شده را مطالعه فرموده باشید حتما بیاد خواهید آورد که بنده در آنجا گفته ام که هر Story ایه   Product Backlog که می خواهد وارد  Sprint Backlog بشود برای آن Story یک Index Card درست می نماییم همانند شکل زیر :

تجربه نشان داده است که باید تمام حالت های این Task را در پشت این Index Card  یادداشت کرد که در واقع راهنمای TDD ما خواهد بود . در همان جلسه Sprint Planning  باید تمام حالات ممکن یک Task معلوم و پشت Index Card  و یا در برنامه های Issue Tracker مانند Jira ثبت شود . یعنی اگر ما یک فهم خوب از یک Story داشته باشیم و تمام حالاتی که ممکن است اتفاق بیفتد را بدانیم به راحتی می توانیم TDD را پیاده سازی نماییم . پس باید قبل از پیاده سازی یک Task کامل آن مورد بحث قرار بدهیم و تمام حالات را دربیاوریم و بنابه حالات ممکن تست طراحی نماییم و بعد پیاده سازی نماییم . به یک مثال در همین باب توجه نمایید :

فرض کنید ما در حال پیاده سازی یک وب سایت می باشیم . Task جاری ما پیاده سازی یک اعتبارسنج رمز عبور (Password Validation) می باشد . Story ما به شرح زیر است :

کاربران سیستم باید در هنگام ثبت نام از رمز عبور امن (Secure) استفاده نمایند . بدین صورت که حداقل طول رمز عبور باید 6 کاراکتر و در رمز عبور باید حداقل از یک حرف ,  یک عدد و یک علامت استفاده شده باشد .

ما برای وضوح بیشتر این Task یک سری  Test Case آماده می کنیم  و مشتری و یا Product Owner اعلام می کند که اینها معتبر  می باشند : p@ssw0rd, @@@000dd, p@ss w0rd و اینها نامعتبر می باشند :   p@ss3, passw0rd, p@ssword, @@@000 .

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

خوب خیلی ساده شد . ما هم اکنون می دانیم چند تا تابع باید بنویسیم . تابع های ما یک رشته را به عنون آرگومان قبول می کنند و یک مقدار Boolean را به عنوان خروجی تابع باز می گردانند . تست نوشتن برای این توابع که اصلا مشکل نیست  . لیست توابع تست که  نیاز داریم به شکل زیر می باشد :

test_valid_returns_true_when_all_conventions_met
test_valid_returns_false_when_password_less_than_6_chars
test_valid_returns_false_when_password_missing_symbol
test_valid_returns_false_when_password_missing_letter
test_valid_returns_false_when_password_missing_number

مثلا اگر بخواهیم تابع تست test_valid_returns_false_when_password_less_than_6_chars را پیاده ساز ی بکنیم ,  به شکل پایین در میآید : (نمونه کد در زبان #C نوشته شده است)

[Test]
public void test_valid_returns_false_when_password_less_than_6_chars()
{

//1
CsPasswordValidator  iValidator=new CsPasswordValidator();

//2
bool result=iValidator.Is6CharPassword(«SirAsad«);

//3
Assertion.AssertEquals(true, result);
}

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

یاشیاسیز

دسته‌ها:Agile, TDD, Unit Testing برچسب‌ها: , , ,
  1. SirAsad
    آوریل 8, 2010 در 11:35 ق.ظ.

    در همین باب مطلب زیر نیز توصیه می شود :

    http://blogs.microsoft.co.il/blogs/dhelper/archive/2010/04/06/the-day-i-understood-tdd.aspx

  2. دوست
    آوریل 8, 2010 در 4:24 ب.ظ.

    كتاب‌هايي كه در مورد asp.net mvc در سال جاري منتشر شده‌اند تمامشون بر اساس TDD جلو رفتن و توضيح دادن.

  1. No trackbacks yet.

پاسخی بگذارید

در پایین مشخصات خود را پر کنید یا برای ورود روی شمایل‌ها کلیک نمایید:

نشان‌وارهٔ وردپرس.کام

شما در حال بیان دیدگاه با حساب کاربری WordPress.com خود هستید. بیرون رفتن / تغییر دادن )

تصویر توییتر

شما در حال بیان دیدگاه با حساب کاربری Twitter خود هستید. بیرون رفتن / تغییر دادن )

عکس فیسبوک

شما در حال بیان دیدگاه با حساب کاربری Facebook خود هستید. بیرون رفتن / تغییر دادن )

عکس گوگل+

شما در حال بیان دیدگاه با حساب کاربری Google+ خود هستید. بیرون رفتن / تغییر دادن )

درحال اتصال به %s

%d وب‌نوشت‌نویس این را دوست دارند: