با روش توسعهی آزمونمحور و مجموعهآزمون دادهشده تمرینها را حل کنید.
توسعهی Test-محور (که گاهی توسعهی Test-First یا طراحی Test-محور هم نامیده میشود) روشی است که در آن unit testها را پیش از آنکه حتی یک خط code پیادهسازی بنویسید، مینویسید.
در Exercism، testها همان نیازمندیها هستند!
همهی تمرینهای عملی که روی آنها کار میکنید (همانهایی که مفهوم تازهای به شما نمیآموزند) دستورالعملهایی دارند که بهطور کلی توضیح میدهند چه کاری باید انجام دهید.
این دستورالعملها بهعمد جزئیات پیادهسازی مخصوص هر زبان برنامهنویسی را در بر نمیگیرند، چون میان بیش از ۷۰ مسیر زبانی Exercism مشترکاند.
بعضی از مسیرهای زبانی جزئیات دقیقتری هم به آنها اضافه میکنند، اما همه این کار را نمیکنند.
وقتی کار روی یک تمرین عملی را شروع میکنید، دستورالعملها را با دقت بخوانید.
این دستورالعملها نمای کلیای از شیوهی پیادهسازی یک راهحل به شما میدهند.
اما برای درک نیازمندیهای کامل و دقیق، باید خود testها را بخوانید:
- آیا نتیجه باید نوع خاصی از ساختار داده باشد؟
- آیا نتیجه باید به ترتیب خاصی مرتب شود؟
- انتظار میرود استثناها را چگونه مدیریت کنید؟ و از این قبیل.
یک تمرین را زمانی حل کردهاید که همهی testهای ارائهشده اجرا شوند و پاس شوند.
به بیان دیگر، راهحل شما فقط یک برداشت از دستورالعملها که «درست به نظر میرسد» نیست؛ راهحل شما برنامهای است که testهای دادهشده را برآورده میکند.
testها نیازمندیهای کامل تمرین را نشان میدهند.
Exercism چگونه TDD را به کار میگیرد؟
ما کار نوشتن یک مجموعهی unit test را برایتان انجام دادهایم.
هدف شما نوشتن راهحلی است که فقط بهاندازهی لازم code داشته باشد تا همهی آن unit testها پاس شوند.
این نکته را در نظر داشته باشید: رویکرد TDD به شما کمک میکند به راهحل برسید، اما لازم نیست همینجا متوقف شوید.
اگر میخواهید راهحلتان را فراتر از نیازمندیها گسترش دهید، میتوانید این کار را بکنید.
اگر تصمیم بگیرید با یک منتور کار کنید (و تشویقتان میکنیم وقتی testها پاس شدند این کار را بکنید)، او میتواند به شما کمک کند پیادهسازی اولیهتان را بازآرایی و بهبود دهید، یا حتی unit testهای تازهای پیشنهاد کند.
کار در ویرایشگر آنلاین
وقتی در ویرایشگر code در وبسایت Exercism کار میکنید، میتوانید testها را بخوانید اما نمیتوانید آنها را ویرایش کنید.
هر بار که testها را اجرا کنید، همهی آنها اجرا میشوند، صرفنظر از هر سازوکار «skip»ی که در فایل test آمده باشد.
وقتی چند test شکستخورده دارید، وبسایت در آغاز فقط نتیجهی اولین شکست را نمایش میدهد.
میتوانید روی شکستهای دیگر هم کلیک کنید تا باز شوند!
گاهی ممکن است نتیجهی اول آموزندهترین نتیجه نباشد.
از تعداد زیاد testهای شکستخورده دلسرد نشوید.
تمرکزتان را بگذارید بر اینکه آنها را یکییکی پاس کنید.
کار بهصورت محلی
بسیاری از مسیرها در فایلهای testشان از testهایی استفاده میکنند که «skip» شدهاند.
در آغاز فقط test اول «فعال» است و بقیه غیرفعالاند (اینکه چگونه این اتفاق میافتد، از مسیری به مسیر دیگر فرق میکند).
وقتی مجموعهی test را در محیط خودتان اجرا میکنید، فقط test اول اجرا میشود.
این کار را میکنیم تا شما را تشویق کنیم این گردش کار را دنبال کنید:
- پیش از افزودن هر code تازهای، مجموعهی test را اجرا کنید: باید یک test شکستخورده ببینید.
- بهاندازهی لازم code اضافه کنید تا test پاس شود.
- مجموعهی test را اجرا کنید.
- اگر test همچنان شکست خورد، مرحله ۲ را تکرار کنید.
- وقتی test پاس شد، code خود را به دلخواه بازآرایی کنید و مطمئن شوید همهی testهای فعال همچنان پاس میشوند.
بازآرایی ممکن است شامل این موارد باشد:
- حذف codeهای تکراری،
- تقسیم توابع طولانی به توابع کوچکتر،
- افزودن کامنت، و از این قبیل.
- test بعدی را از حالت «skip» خارج کنید و از مرحله ۱ تکرار کنید.
این مراحل را تکرار کنید تا همهی testها را از حالت «skip» خارج کنید.
وقتی همهی testها پاس شدند، تبریک میگوییم، تمرین را حل کردهاید!
اینکه testها دقیقاً چگونه از حالت «skip» خارج میشوند (یا فعال میشوند)، به مسیر بستگی دارد.
در بعضی مسیرها، ممکن است کامنت کردن یا حذف یک annotation باشد.
در بعضی مسیرها، ممکن است تغییر یک attribute از «درست» به «غلط» باشد.
وقت بگذارید و مستندات مسیر خودتان را بخوانید؛ این مستندات این جزئیات را توضیح میدهد.
برای مسیرهایی که testها را skip نمیکنند، اجرای این گردش کار ممکن است به همین سادگی باشد که testها را کامنت کنید و یکییکی از حالت کامنت خارجشان کنید.
دلیل توسعهی Test-محور
شاید به نظر برسد که «کار را وارونه انجام میدهید»، اما دلایل خوبی وجود دارد که بخواهید پیش از نوشتن code پیادهسازی، unit testها را بنویسید.
-
طراحی.
شما را وادار میکند اول به رابط برنامهتان فکر کنید (اینکه چگونه کارکردش را به دنیای بیرون ارائه میدهد)، نه اینکه مستقیم به این بپرید که code را چگونه پیاده میکنید.
داشتن یک رابط خوبطراحیشده (و قابل test!)، اغلب مهمتر از داشتن یک پیادهسازی کارآمد است.
-
نظم.
نوشتن testها اغلب وظیفهای خستهکننده یا کاری حاشیهای شمرده میشود؛ اما نوشتن testها در ابتدا تضمین میکند که در نهایت بهاندازهی کافی unit test نوشته باشید تا بیشتر یا همهی کارکرد codeتان را پوشش دهید (بهجای اینکه شاید هیچوقت فرصتش را پیدا نکنید).
-
کار کمتر.
اگر چرخهای فشرده را در پیش بگیرید، یعنی یک test بنویسید، سپس codeای بنویسید که آن test را پیاده میکند و بعد test بعدی را بنویسید، code شما بهطور طبیعی رشد میکند.
این کار اغلب (هرچند نه همیشه) به هدر رفتن تلاش کمتری میانجامد؛ در نهایت همهی codeی را که لازم دارید مینویسید و هیچ codeی را که لازم ندارید.
مطالعهی بیشتر
