توسعه آزمایش محور (TDD) یکی از بحث و گفتگوترین روشها در توسعه نرم افزار است. برخی از آنها سوگند می خورند و ادعا می کنند که منجر به کیفیت بهتر کد ، اشکالات کمتری و سیستم های قابل حفظ تر می شود. برخی دیگر – از این رو ، شامل این می شوند که باعث اختلال در بهره وری ، خلاقیت می شود و اغلب به یک بار غیر ضروری تبدیل می شود.
اگر تا به حال با TDD دست و پنجه نرم کرده اید یا احساس کرده اید که شما را کند می کند ، تنها نیستید. در اینجا چرا من نه از TDD استفاده کنید و چرا ممکن است بخواهید مکان آن را در گردش کار خود تجدید نظر کنید.
1 TDD توسعه را کند می کند
TDD قبل از نوشتن اجرای واقعی ، تست های نوشتن را اجرا می کند. در حالی که این در تئوری عالی به نظر می رسد ، در عمل ، آن به طرز چشمگیری کند می شود توسعه، به خصوص در مراحل اولیه یک پروژه وقتی:
- الزامات هنوز در حال تحول هستند.
- شما به سرعت در حال تکرار ایده ها هستید.
- کدی که می نویسید ممکن است تغییر کند یا دور ریخته شود.
در محیط های سریع ، نوشتن تست قبل از اینکه حتی بدانید که اجرای نهایی باید به چه صورت باشد ، اغلب اتلاف وقت است.
2 این جریان و خلاقیت توسعه دهنده را مختل می کند
توسعه دهندگان اغلب وارد یک می شوند حالت جریان جایی که آنها می توانند عمیقاً فکر کنند و مشکلات پیچیده را به طور مؤثر حل کنند. TDD تغییر زمینه ثابت:
- یک آزمون بنویسید.
- برای گذراندن آزمون فقط کد کافی بنویسید.
- Refactor
- تکرار
این چرخه است جنجال و از فکر کردن در مورد مشکل در مورد مشکل جلوگیری می کند. بسیاری از توسعه دهندگان باتجربه ترجیح می دهند روی طراحی تمرکز کنند کد زیبا و ساختار یافته ابتدا ، سپس تست ها را بنویسید پس از آنها یک پایه محکم دارند.
3 همه کد از TDD مزایای آن نیست
TDD برای اجزای منطق سنگین تعریف شده عالی است (مانند الگوریتم مرتب سازی) ، اما در توسعه دنیای واقعی ، کد زیادی اکتشافی استبشر برخی از نمونه هایی که TDD بیشتر از یک مزایا است:
- توسعه UI: رفتار جلو بسیار بصری و تعاملی است. نوشتن تست قبل از عناصر UI حتی وجود دارد غیر عملی است.
- یادگیری ماشین / AI: خروجی های مورد انتظار همیشه قطعی نیستند و تعریف موارد دقیق آزمایش را دشوار می کند.
- توسعه بازی: فیزیک ، رفتار هوش مصنوعی و تولید رویه ای به طور مرتب در گردش کار محور قرار نمی گیرند.
در این موارد ، آزمایش دستی ، ورود به سیستم و اشکال زدایی اغلب بسیار مؤثرتر از نوشتن تست های واحد به صورت مقدماتی هستند.
4 TDD می تواند یک احساس امنیت کاذب ایجاد کند
یکی از بزرگترین استدلال های TDD این است که از اشکالات جلوگیری می کندبشر با این حال ، فقط به این دلیل که کد از آزمایشات عبور می کند به معنای این نیست عاری از اشکال یا خوشبوبشر
چرا؟
- تست ها فقط رفتار مورد انتظار را بررسی می کنند. آنها این کار را نمی کنند گرفتن مسائل ناشناختهبشر
- آزمایشات کتبی ضعیف می تواند منجر شود اعتماد کاذب در کد بد
- بسیاری از اشکالات به دلیل مسائل ادغام، که TDD مستقیماً به آن پرداخته نمی شود.
به جای اینکه از TDD کورکورانه پیروی کند ، توسعه دهندگان باید روی آن تمرکز کنند بررسی کد مناسب ، تست های ادغام و آزمایش در دنیای واقعیبشر
5 TDD کد خوب را تضمین نمی کند
طرفداران TDD ادعا می کنند که منجر به معماری بهتر می شود ، اما این فقط درست است اگر توسعه دهنده از قبل می داند چگونه نرم افزار خوبی را طراحی کندبشر
- طراحی خوب از تجربه و تفکر انتقادی، نه قوانین آزمایشی سفت و سخت.
- نوشتن تست های خیلی زود می تواند شما را قفل کند معماری های زیر حد متوسط، ساخت مجدد مجدد آینده.
توسعه دهندگان عالی فقط از فرایندها پیروی نمی کنند ، آنها با انتقادی فکر کنید درباره زمانی که یک روش مفید است و چه زمانی فقط کار اضافی است.
6 به هر حال اکثر شرکت ها به سختی از TDD پیروی نمی کنند
با وجود محبوبیت در تئوری ، تیم های بسیار کمی سخت در عمل به TDD پایبند باشید. در عوض بسیاری از شرکت ها:
- نوشتن آزمایشات بعد از اجرای برای اطمینان از صحت
- بیشتر روی تمرکز کنید ادغام و آزمایش پایان به پایان بیش از تست های واحد سفت و سخت.
- اولویت بندی کردن تکرار سریع و تحویل بیش از رویکرد ساختاری TDD.
یکبار کنت بک، خالق TDD ، اعتراف کرده است که دیگر از نظر مذهبی از آن پیروی نمی کند.
بنابراین ، آیا باید TDD را کاملاً خندق کنید؟
لزوماً TDD جای خود را دارد، اما این راه حل جهانی نیست که برخی آن را به وجود می آورند. این فقط یک ابزار در بین بسیاری است.
👉 چه موقع از TDD استفاده کنید:
✅ هنگام کار روی مؤلفه های حساس منطق سنگین (به عنوان مثال ، کامپایلرها ، محاسبات مالی ، سیستم های احراز هویت).
✅ هنگام ساختن سیستمی که به قابلیت اطمینان بالا نیاز داردبشر
✅ هنگام کار در تیمی که ارزش توسعه اول را ارزیابی می کند.
👉 چه موقع از TDD جلوگیری کنید:
❌ هنگام کار بر روی سرعت های در حال تحول سریع.
❌ هنگام توسعه برنامه های سنگین UI.
❌ هنگام کاوش ایده ها و معماری های جدید.
پایان
TDD یک گلوله نقره ای نیست. در حالی که ممکن است در برخی شرایط خوب کار کند ، کورکورانه استفاده از آن برای هر پروژه می تواند شما را کند کند ، گردش کار شما را مختل کند و منجر به پیچیدگی غیر ضروری شودبشر به جای مجبور کردن خود به یک ذهنیت TDD ، روی نوشتن تمرکز کنید کد خوب اول، سپس تست هایی را اضافه کنید که بیشترین ارزش را داشته باشند.
در پایان روز ، آنچه مهم است ارائه نرم افزار با کیفیت بالا– نه کورکورانه از یک روش به خاطر آن پیروی کنید.
این ویدیوی YouTube از ThePrimetime بینش خوبی به من داد ، شما باید آن را بررسی کنید.
https://youtu.be/0ihsnvuzs3s
در نظرات به من اطلاع دهید که چه فکر می کنید و چگونه TDD را در پروژه های خود اجرا کرده اید
