۳۰ روز با TDD: روز سیزدهم - ویژگی‌های بیشتر stub
روز سیزدهم از مجموعه نوشته‌های ۳۰ روز با توسعه آزمون محور
در روز دوازدهم با stub ها آشنا شدیم. نوشته روز سیزدهم به زبان انگلیسی را در این آدرس می‌توانید مطالعه کنید.
زمان بازبینی کد
من دوست دارم به صورت متناوب با تیم برای بازبینی کدها جلسه داشته باشم. بعضی تیم‌ها زمان‌های برنامه‌ریزی شده برای این کار دارند و بعضی ندارند. یکی از چیزهایی که دوست دارم پایه اصلی جلسات بازبینی کد باشد، بخش‌های مهم برنامه هستند که یا پیجیده‌اند یا بخش‌های زیاد دیگری با آن‌ها در ارتباطند. بازبینی کد این بخش‌ها کمک می‌کند مطمئن شویم که مشکلات پیچیده به ساده‌ترین شکل ممکن هستند و همه تیم (حتی شده به صورت کلی) بدانند آن بخش‌های پیچیده و مهم چطور کار می‌کنند.
زمان دیگری که وقت بازبینی کد است موقع ورود یک برنامه‌نویس جدید به تیم است. این برنامه‌نویس جدید ممکن است یک برنامه‌نویس تازه‌کار که اخیراً از دانشگاه آمده باشد یا خیلی ساده یک نفر که به تازگی وارد تیم شما شده است. من دوست دارم که چند task اولی که انجام دادند را بازبینی کنم تا مطمئن شوم درک درستی از مساله دارند و با بخش‌هایی از برنامه که تا به حال نوشته شده آشنا هستند و از استانداردهای کدنویسی ما معطلند. از آنجایی که خیلی از خوانندگان این سری نوشته در TDD تازه‌وارد هستند، به نظر می‌رسد زمان مناسبی برای بازبینی کدها باشد!
در مطلب قبلی ما کد زیر را برای متد PlaceOrder در کلاس OrderService نوشتیم:
کد خیلی ساده‌ای است. برای اینکه تایید کنیم مطابق نیاز تجاری است یک تست داریم (که پیش از کد بالا ایجاد شده است)
تست ما برای تایید صحت کار مورد نیاز خوب به نظر می‌رسد. اما به عنوان یک معمار، یک نکته قابل تامل می‌بینم. در طی سالیان با برنامه‌های متعددی کار کردم و مشکلات کارآیی (performance) گاه و بیگاه را دیده‌ام. دلایل متعددی برای مشکلات performance وجود دارد، اما مشکل مشترکی که من دیدم، فراخوانی‌های متعدد غیرضروری به منابع خارجی مانند دیتابیس بوده است. فراخوانی دیتابیس به صورت نسبی کند است، به خصوص به نسبت زمانی که از حافظه یا mock استفاده می‌کنید. این باعث می‌شود که پیدا کردن این طور مشکلات از طریق آزمون واحد مشکل باشد و البته هیچ جریمه مرتبط با performance ای هم در کار نیست چرا که از mock استفاده می‌کنیم. به عنوان معمار/برنامه‌نویس ارشد/هر عنوان دیگر پروژه می‌خواهم مطمئن شوم که Save در OrderDataService یک بار فراخوانی می‌شود. خوشبختانه JustMock امکانی برای این منظور دارد که stub چند بار فراخوانی شود.
چند تغییر در تست اولیه ایجاد کردم. اول، بخش Arrangement در mock را به سه خط تقسیم کردم تا خواندن این مثال راحت‌تر باشد. همچنین متد OccursOnce را به انتهای arrangement اضافه کردم که به JustMock می‌گوید این متد دقیقاً یک بار باید اجرا شود و هر تعداد دیگر اجرا یک خطا خواهد بود. همچنین فراخوانی Mock.Assert را اضافه کردم. این فراخوانی به mock می‌گوید که قوانین تعریف شده (مثل اجرای یک بار متد) را تایید کند. در این مثال ما تنها یک قانون داریم که متد Save باید دقیقاً یک بار فراخوانی شود. اگر متد Save بیش از یک بار فراخوانی شود تست ما fail خواهد شد.
برای نشان دادن fail شدن من فراخوانی متد Save را در PlaceOrder کامنت می‌کنم و همچنین Assert.Equal را نیز کامنت می‌کنم تا مطئن شوم که تایید قوانین mock اولین fail است که پیدا می‌شود. وقتی تست را اجرا می‌کنم تست fail می‌شود و دلیل fail شدن یکسان نبودن تعداد دفعات فراخوانی با تعداد دفعات فراخوانی مورد انتظار است.
JustMock انتظار دارد که متد یک بار فراخوانی شود (محدوده مورد انتظار بین ۱ بار و ۱بار است) و همانطور که در نوشته‌های بعدی خواهید دید حد پایین و بالای تعداد فراخوانی‌ها را می‌توانیم تنظیم کنیم. چون از OccursOnce استفاده کردیم محدوده ما بین یک و یک است.
بعد از برداشتن کامنت‌ها اگر دوباره تست را اجرا کنیم تست pass خواهد شد.
ادامه دارد…