چرخه “قرمز-سبز-ریفکتور”
تو این چرخه میگه اول تست رو بنویس بعد کد اصلی، من تو مدل xp این مورد رو دیدم و تو یه پروژه تمرینی از این روش رفتم جلو
هم زمان زیادی ازم گرفت هم کد پروژم خیلی کثیف شده بود هم بسیار گیج کننده بود ! مثلا من که هنوز نمیدونستم ورودی های سازنده کلاسم چیه چطوری میتونم تو بدنه تست از اون کلاس استفاده کنم یا اصلا کلاس من چه توابعی داره !
ما هم unittest داریم هم feature ، مسلما باید بدونیم چه کلاس های داریم با چه متد هایی و چه خروجی هایی
عملا داریم یه جوری کلاس ها و متد ها رو تو برگه، تو ذهنمون ، الگوریتمشو مینویسیم یا هر روشی غیر از کد نوشتن پیاده سازی میکنیم که ببینیم چه کلاس هایی، سازنده هایی، متد هایی و ... داریم
خوب از اول چرا کد برنامه را ننویسیم بعد تست اونو بنویسیم ؟
یه خورده این روش برام گنگه اگه میشه یه جور راهنماییم کنید
سلام و احترام
ما باید بدونیم که اصلا اون تابع قراره چی کارنه. میایم با خودمون عملکر یه تابع رو مرور میکنیم تا طبق عملکردی که داره براش تست مینویسیم. وقتی که ما برای تابعی که هنوز وجود نداره تست مینویسیم در واقع داریم مسیر اون تابع رو مشخص میکنیم، پس مشخصه کد اون تابع قرار چی باشه و اگه از مسیر خودش خارج شد تست ما پاس نمیشه و نشون میده که طبق هدفش عمل نمیکنه
موفق باشید.
سلام ...
ببینید زمانی که شما میخواید یه سرویس یا یک کلاس رو بنویسید قطعا میدونید که اون کلاس یا سرویس قرار هست که چه کاری انجام بده و خروجی نهاییش چی باشه .. و حالا با توجه به اون دانشی که دارید از کار اون کلاس میاید و یه مقداری ریزتر میشید که با توجه به اینکه من میدونم کلاسم قرار هستش که چه کاری انجام بده میتونم مراحل رو شبیه سازی کنم داخل ذهنم .. پس حالا اون مراحل رو به صورت منطقی میشینم و براش کد مینویسم .. مثلا اگر شما دارید یک تابع تعریف میکنید و نمیدونید که ورودی این تابع چی هستش و زمانی که دارید بدنه تابع رو مینویسید تعداد ورودی ها رو مدام عوض میکنید یعنی در واقع هنوز درک درستی از اون تابع ندارید که قرار هستش که چه کاری انجام بده ... در این حالت شما نمیتونید تست بنویسید برای اون تابع ... چون هنوز مسیر و دقیقا کار اون تابع به خصوص رو نمیدونید ... در جلسات مربوط به دوره Clean Code اصل Single Responsibility رو که با هم بررسی کنیم بهتر میتونید این موضوع رو درک کنید.
اگر بخوام یک مثال واقعی هم بزنم به عنوان مثال شما یه سرویس اطلاع‌رسانی دارید که قرار هستش پیام کوتاه و ایمیل بزنه به کاربرها ... برای طراحی این سرویس مسیر این سرویس به این صورت هستش که خب قاعدتا ۲ تا متد داره که یکی ایمیل ارسال میکنه و یکی دیگه پیام کوتاه ... پس در واقع من حداقل ۲ متد تست دارم که هر کدوم از اینها رو میاد و تست میکنه .. حالا در مورد ورودیها یکی از اون پیام رو دریافت میکنه و شماره تلفن کاربر .. و یکی دیگه پیام و ایمیل رو دریافت میکنه ... این میشه منطق این سرویس .. حالا اگه شما داخل طراحی این سرویس به این مورد رسیدید که به جای ایمیل کاربر باید مدل خود User رو ارسال کنید پس اینجا دقیقا شما هنوز درک درستی از نحوه کار اون سرویس پیدا نکردید .. چون اون سرویس کاری نباید به این داشته باشه که این شماره‌ای که من دارم میگیرم برای مدل User هستش یا برای مدل Company هستش. ... این سرویس فقط یک شماره تلفن نیاز داره ... یعنی دقیقا تست رو درست و منطقی نوشتید ... و چون میخواید او تست رو پاس کنید مجبور میشید براساس اون چیزی که داخل تست فکر کردید کدتون رو بنویسید ... در واقع اون تستی که اول نوشتید خیلی منطقی‌تر و درست تر به سرویس و یا متد و روش اجرای اون نگاه میکنه تا زمانی که خودتون دارید کدنویسی اون متد رو انجام میدید.
