توسعه تست محور یا TDD
همانطور که در محافل توسعه دهندگان با علاقه شناخته می شود جنبه مهمی از فرآیند توسعه نرم افزار است. از طریق این رویکرد، آزمایش عملکرد یک کد خاص آسان تر است. موارد تست برای هر یک از عملکردهای برنامه نرم افزاری ایجاد می شود، و زمانی که یک عملکرد خاص در یک آزمایش ناموفق باشد، روی کد دوباره کار می شود و کدهای جدید ایجاد می شود. کد جدید همچنین باید تست را پشت سر بگذارد و بدون اشکال باشد. توسعه‌دهنده فقط در صورتی باید کد جدیدی بنویسد که تست خودکار کد شکست خورده باشد، بنابراین برای هر عملکرد، هر چند کوچک، یک مورد آزمایشی وجود خواهد داشت. و TDD همه چیز در مورد طراحی و توسعه تست ها برای هر عملکرد منفرد در برنامه است.
نام Test Driven Development نشان می‌دهد که فرآیند انجام تست‌ها به روش صحیح است که توسعه نرم‌افزار را هدایت می‌کند. از این رو، خود فرآیند ریشه های خود را از روش شناسی Agile و برنامه نویسی Extreme می گیرد. این فرآیند تضمین می‌کند که توسعه‌دهندگان کدی مقاوم و طولانی مدت ایجاد و نگهداری می‌کنند.
بنابراین فرآیند TDD این است که ابتدا آزمون واحد را بنویسید، و اگر آزمایش ناموفق بود، سپس تغییرات کد را اجرا کنید. این به جلوگیری از تکرار کد نیز کمک می کند. کل کار بر روی نوشتن و تصحیح تست های شکست خورده قبل از توسعه واقعی اجرا می شود. با این حال، برای اینکه theTDD با موفقیت کار کند، توصیه می‌شود که موارد تست را روی موارد آزمایش ساده بنویسید. برای منطق پیچیده کسب و کار، نوشتن ترکیبی از موارد آزمایشی و دستیابی به موفقیت کامل واقعاً دشوار است. این احتمال وجود دارد که نوشتن برخی از تست ها را از دست بدهید، بنابراین اصلا کار آسانی نیست.
تفاوت بین TDD و تست سنتی
آزمایش سنتی نسبت به TDD وقت گیرتر است و بر اساس تکرار یک چرخه کوتاه توسعه است. ابتدا تست از ابتدا نوشته می شود، سپس کد برنامه نوشته می شود و به دنبال آن رفتار مورد نظر سیستم بیان می شود. پس از گذراندن آزمون کتبی (بررسی صحت کار کدهای نانوشته)، اصلاح مجدد کد نوشته شده انجام می شود.
در ابتدا، TDD نیز زمان‌بر خواهد بود، اما با گذشت زمان، توسعه‌دهنده به آن عادت می‌کند زیرا فرآیند توسعه ساختارمندتر می‌شود. به عنوان مثال، هنگامی که یک توسعه دهنده را استخدام می کنید، آنها تصمیم می گیرند چه چیزی بنویسند و سپس چگونه آن را بنویسند.
آزمایش سنتی زمانی موفقیت آمیز است که یک یا چند نقص را به درستی پیدا کند. درست مثل TDD. پیدا کردن نقص در واقع نشانه خوبی است زیرا در این صورت می‌دانید که باید مشکل را حل کنید و از آنجا ادامه دهید. TDD همچنین هنگام انتشار برنامه به شما اطمینان بیشتری می‌دهد و تضمین می‌کند که الزاماتی را که برای آن تعریف شده است برآورده می‌کند.
در آزمایش سنتی، تمرکز بیشتر بر روی طراحی مورد آزمایش است، در حالی که در TDD، تمرکز بیشتر بر روی کد تولید است تا بررسی شود که آیا آزمایش طبق برنامه عمل می کند یا خیر.
TDD به شما 100% پوشش تست می دهد، جایی که تست برای هر خط کد انجام می شود، این مورد در آزمایش سنتی نیست.
وقتی دامنه پروژه واقعاً بزرگ است، باید در حین انجام آزمایشات واقعاً دقیق باشید. و این احتمال وجود دارد که آزمایش به تاخیر بیفتد و از محدودیت های بودجه و زمانی عبور کند.
نوشتن TDD ممکن است سخت باشد، و ممکن است زمان توسعه را کاهش دهد، اما قطعا در دراز مدت نتیجه خواهد داد.
یکی دیگر از معایب TDD این است که این مفهوم برای کدهای قدیمی موجود دشوار است.
همیشه خوب است که قبل از انتشار یک پروژه، تست را شکست دهید، زیرا در این صورت خواهید فهمید که یک آزمون معتبر را اجرا کرده اید. از طریق TDD، خواهید دانست که سیستم شما الزاماتی را که برای آن طراحی شده است برآورده می کند. بنابراین تمرکز بیشتر بر روی کد تولید برای TDD است، زیرا تضمین می کند که آیا آزمایش به درستی کار می کند یا خیر. و زمانی که نرم افزار تمام الزامات طراحی شده برای آن را برآورده کند.
مراحل مختلف توسعه آزمایش محور
سه مرحله مختلف TDD وجود دارد: قرمز، سبز و Refactor
پیروی از این ترتیب مراحل تضمین می کند که برای کدی که می نویسید تست دارید، بنابراین باید فقط برای تست هایی که انجام می دهید کدها را بنویسید.
مرحله قرمز
ایده مرحله قرمز این است که تست را با شکست مواجه کنیم، و سخت‌ترین مرحله نیز به این دلیل است که توسعه‌دهی باید تستی را بدون کد بنویسد. توسعه دهندگان جدید باید این کار را دشوار بدانند زیرا آنها در مورد اینکه چه چیزی را بدون داشتن کد آن آزمایش کنند سردرگم می شوند. اما این یک امر عادی است و با تجربه صاف می شود. تست اول بدون کد نوشتن و برای اعلام کلاس و متد نوشته می شود و تست خطای کامپایل خواهد داشت. مرحله بعدی رفع خطای کامپایل و اجرای آزمایش برای شکست در آن است. این باعث ایجاد پرچم قرمز می شود.
فاز سبز
بعد از مرحله قرمز، مرحله بعدی نوشتن کد است. این کد باید اولین تست را پشت سر بگذارد. نوشتن کد کافی برای اطمینان از موفقیت در آزمون اول، مانعی است که بسیاری از توسعه دهندگان در ابتدا با آن روبرو هستند. زیرا در تست بعدی باید با شکست مواجه شود و به دنبال آن کد جدیدی برای عبور از آنها ارائه می شود.
فاز رفرکتور
در دو مرحله اول، که ابتدا باید آزمون مردود شود و سپس آن را بگذراند، هدف این بود که پس از آن آزمون ها را با موفقیت پشت سر بگذاریم. اما در مرحله Refractor، عوامل دیگری مانند کیفیت کد، قابلیت نگهداری کد، خوانایی کد و غیره باید در نظر گرفته شوند. بنابراین تمرکز در اینجا بر روی آن جنبه‌ها است، بنابراین تست‌های واحد بر روی آنها تمرکز خواهند کرد. در مرحله refactoring، لازم نیست نگران از دست دادن جنبه عملکردی باشید، زیرا زمانی که تغییرات کد اتفاق می افتد، موارد تست به طور خودکار با بخش عملکرد نیز مطابقت خواهند داشت.
TDD به خوبی با روش Agile مطابقت دارد
کاملاً بدیهی است که الزامات پروژه ممکن است در مرحله توسعه به خوبی تغییر کند، بنابراین داشتن TDD در همکاری با توسعه Agile قطعاً آن را موفق می کند و پروژه هایی را مطابق با نیازهای مشتری می سازد. با توسعه مبتنی بر آزمایش، بازخورد قبلی در مورد پروژه دریافت می کنید که می توانید به راحتی روی آن کار کنید.
همچنین به پیش‌بینی و کاهش تنگناهای حیاتی کمک می‌کند و تضمین می‌کند که پروژه طبق برنامه پیش می‌رود. تیم‌های توسعه‌دهنده می‌توانند زمان زیادی را صرفه‌جویی کنند، زیرا آزمایش‌ها خیلی زودتر از زمان توسعه پروژه ایجاد می‌شوند و نیازی نیست نگران اسکریپت‌های آزمایشی گسترده باشند.
نتیجه
توسعه تست محور تکنیکی است که در واقع زمان بر است، اما از این نظر ارزشمند است که با دریافت بازخورد صحیح در مورد پروژه و شناسایی اشکالات، پروژه شما را در مسیر درست هدایت می کند. با این حال، این گزینه بسیار بهتر از آزمایش سنتی است زیرا به زمان و هزینه بیشتری نیاز دارد.
لینک های جالب :
توسعه دهندگان لاراول: چگونه برنامه های واقعا خوب را پیدا کنیم!