۳۰ روز با Test Driven Development

سپتامبر سال گذشته آقای James Bender در وبلا‌گ‌های تلریک یک مجموعه نوشته منتشر کرد به نام ۳۰ روز با TDD. 

در این سری از نوشته‌های آرایه، ترجمه آزادی برای ۳۰ روز با TDD خواهم داشت و با هم اصول و قواعدش را یاد می‌گیریم. همچنین در توییتر می‌توانید مباحث مرتبط با این موضوع را با هشتگ 30RoozTDD# دنبال کنید.

TDD یا Test Driven Deveploment یک روش تولید نرم‌افزار است که ایده ساده‌ای دارد:

اولین کاری که برنامه‌نویس انجام می‌دهد نوشتن تست بر اساس ویژگی مورد انتظار فعلی نرم‌افزار (specification) است که روی آن کار می‌کند. این تست‌ها باید fail شوند چرا که قابلیتی که می‌خواهند آزمایش کنند هنوز به وجود نیامده است. در این شرایط کار برنامه‌نویس این خواهد بود که ساده‌ترین کد ممکن را بنویسد یا تست pass شود. اگر نرم‌افزار امکانات مورد انتظار (specification) بیشتری دارد، تست‌های بیشتری بنویسید و چرخه refactor و بهینه کردن کد را ادامه دهید. وقتی همه مشخصات نرم‌افزار تست داشتند و تست‌هایشان pass می‌شد نرم‌افزار شما آماده است. عرضه‌اش کنید!

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

مجموعه نوشته‌های سری ۳۰ روز با TDD

۱- روز اول: TDD چیست و چرا باید از آن استفاده کنم؟
۲- روز دوم: مروری بر اصول شی گرایی
۳- روز سوم: اولین تست شما
۴- روز چهارم: Pass کردن اولین تست
۵- روز پنجم: کد SOLID ایجاد کنید
۶- روز ششم: تزریق وابستگی (Dependency Injection) چیست؟
۷- روز هفتم: Software Factories و DI Frameworks
۸- روز هشتم: برخورد با defect‌ ها
۹- روز نهم: مقدمات Refactoring
۱۰- روز دهم: بررسی بیشتر Refactoring و NUnit
۱۱- روز یازدهم: درباره Mocking
۱۲- روز دوازدهم: کار با Stub ها
۱۳- روز سیزدهم: ویژگی‌های بیشتر stub
۱۴- روز چهاردهم:ساده همیشه به معنی واضح نیست قسمت اول
۱۵- روز پانزدهم: ساده همیشه به معنی واضح نیست قسمت دوم
۱۶- روز شانزدهم: استفاده از پارامترهای مشخص در stub ها
۱۷- روز هفدهم: تعیین ترتیب اجرا در MOCK ها
۱۸- روز هجدهم: بازبینی Refactoring قسمت اول