نظرتون درباره تست نویسی چیه؟ بیاید یه چالش راه بندازیم و این هیولای دوستداشتنی رو اهلی کنیم!

بیاید راستشو بگیم، وقتی حرف از تست‌نویسی می‌شه، بیشترمون قیافه می‌گیریم انگار یکی گفته "بیا ظرف‌ها رو بشور!" یه سری می‌گن: "وقت نداریم"، یه سری دیگه: "این واسه پروژه‌های خیلی بزرگه" و بعضیا هم کلاً: "حال نداریم." ولی خب، اگه تا حالا تو یه تیم فنی یا پروژه شخصی بودی، می‌دونی که بدون تست، هر تغییر کوچیک ممکنه مثل دومینوی خرابکاری همه چیز رو بریزه بهم!

واقعیت اینه که ما تست‌نویسی رو جدی نمی‌گیریم چون بیشتر حواسمون به اینه که پروژه رو سریع تحویل بدیم، نه اینکه مطمئن باشیم بعدش زندگی آسون‌تری داریم. اما صبر کن! بیاید یه نگاهی به Unit Testing بندازیم و ببینیم چرا انقدر مهمه و چطوری می‌تونه کارمون رو متحول کنه.

تست واحد (Unit Testing) چیه؟

تصور کن داری یه ماشین می‌سازی. قبل از اینکه کل ماشین رو سرهم کنی، میای تک‌تک قطعاتش رو تست می‌کنی. چرخ‌ها رو می‌چرخونی، فرمان رو تکون می‌دی، مطمئن می‌شی ترمز درست کار می‌کنه. چرا؟ چون نمی‌خوای وسط جاده بفهمی یه جای کار می‌لنگه، درسته؟

تست واحد هم همینه! یعنی هر بخش کوچیکی از کدت (مثل یه تابع، یه متد یا یه کلاس) رو جداگانه تست می‌کنی و می‌بینی همون‌طور که باید، کار می‌کنه. انگار داری به این قطعه کوچیک از کدت یه مُهر تضمین می‌زنی و می‌گی: "آی مردم! من مطمئنم که این بچه هر وقت اجرا بشه، یه چیزی رو خراب نمی‌کنه!" 😄

چطوری باید تست واحد بنویسیم؟

۱.توسعه مبتنی بر تست Test-Driven Development (TDD): این سبک رو وقتی دوست داری که می‌خوای خیلی شسته‌رفته کار کنی. اول تست می‌نویسی و بعد کد. شاید به نظرت عجیب بیاد، ولی این روش باعث می‌شه کمتر کد بزنی، چون دقیقاً می‌دونی چی می‌خوای.

۲. شبیه‌سازی (Mocking): فرض کن داری یه سیستم پیچیده رو تست می‌کنی، ولی نمی‌خوای همه‌چیز رو بیاری تو تستت. اینجا از Mock استفاده می‌کنی؛ یعنی یه نسخه الکی (اما هوشمند) از قسمت‌هایی که نیاز داری، می‌سازی.

۳. آزمون هرم (Pyramid Testing): این استراتژی می‌گه بیشتر تمرکزت روی تست‌های واحد باشه، بعد برو سراغ تست یکپارچه سازی(Integration) و بعد End-to-End. انگار داری یه هرم می‌سازی

خب واقعاً چرا باید تست بنویسیم؟ بذار چند تا دلیل خفن برات بیارم:

1. کیفیت بالا:
با تست واحد، مطمئن می‌شی که هر تغییر کوچیکی تو کدت، سیستم رو به فنا نمی‌ده. یه جورایی خیال خودت و تیمت رو راحت می‌کنی که همه چیز سر جاشه.

2. کمتر شدن باگ‌ها:
تست‌نویسی دقیقاً مثل واکسن زدنه. شاید اولش وقت و انرژی بگیره، ولی بعداً جلوی مریضی‌های سنگین رو می‌گیره. باور کن پیدا کردن یه باگ تو محیط تولید مثل درمان سرماخوردگی نیست، بیشتر شبیه جراحی قلب بازه!

3. اعتمادبه‌نفس:
وقتی همه تست‌ها سبز بشن، حس می‌کنی یه ابرقهرمانی که می‌تونه با یه دست کد بزنه و با دست دیگه دنیا رو نجات بده. انگار کدت داره بهت می‌گه: "من آماده‌ام، بزن بریم!"

4. سرعت در توسعه:
شاید اولش فکر کنی تست‌نویسی سرعتت رو کم می‌کنه، ولی در درازمدت کمک می‌کنه کمتر وقتت رو روی رفع مشکلات تکراری بذاری و با خیال راحت پیش بری. مثل اینه که اول مسیر یه پلی بسازی تا لازم نباشه هر بار از رودخونه شنا کنی!

همون‌طور که هر چیز خوبی یه سری چالش داره، تست‌نویسی هم بی‌ایراد نیست. بیایید منصف باشیم:

1. وقت‌گیر:
تست‌نویسی زمان می‌بره، مخصوصاً وقتی تیمت کوچیک باشه یا تحت فشار باشی که پروژه رو سریع تحویل بدی. انگار داری برای یه ماراتن آماده می‌شی، ولی کارفرما می‌خواد صد متر رو همون لحظه بدوی!

2. نیاز به دانش فنی:
نوشتن تست خوب، خودش یه هنره. مثل رانندگی نیست که با آزمون و خطا یادش بگیری؛ باید برایش وقت بذاری و یاد بگیری چی کجا تست بشه. اوایل شاید کمی چالش‌برانگیز باشه، ولی وقتی یاد بگیری، دیگه به کارت نمی‌آدازن.

3. پوشش محدود:
تست‌های واحد همه مشکلات رو نمی‌گیرن. مثل اینه که فقط چرخ‌های ماشین رو چک کنی، ولی موتور رو ندیده بگیری. برای اینکه همه چیز رو پوشش بدی، به تست‌های دیگری مثل Integration و End-to-End نیاز داری.

کجاها Unit Testing کم‌فایده‌ست؟

حقیقت اینه که تست‌نویسی همیشه هم راه‌حل مناسبی نیست. بعضی مواقع بهتره بدون دردسر پیش بری. مثلاً:

1. پروژه‌های کوچیک:
اگه پروژه کوچیکه و تغییراتش محدود، شاید نوشتن تست اصلاً ارزش وقت گذاشتن نداشته باشه. برای این جور مواقع، شاید به جای وقت گذاشتن روی تست‌ها، بهتر باشه سریع‌تر کد رو بنویسی و تمامش کنی.

2. تیم‌های کوچک با منابع محدود:
وقتی تیم کوچیکی داری و منابع (یعنی آدم و زمان) هم محدود، تست‌نویسی ممکنه اولویت بالایی نداشته باشه. در این شرایط باید انتخاب کنی که کجاها بیشتر به کار میاد و کجا می‌تونی فشاری که رو دوش تیم هست رو کمتر کنی.

3. ددلاین‌های سنگین:
وقتی مشتری می‌خواد "دیروز پروژه رو تحویل بگیره"، تست‌نویسی معمولاً می‌ره تو لیست اولویت‌ها و سقوط آزاد می‌کنه! این مواقع بیشتر دنبال تحویل سریع و بدون دردسر هستی تا اینکه بخوای وارد جزئیات تست بشی.

تست‌نویسی همیشه عالی نیست، اما در خیلی از شرایط می‌تونه مثل یه ابرقهرمان عمل کنه که جلوی فاجعه‌ها رو می‌گیره.

تجربه شخصی

تو یکی از پروژه‌های بزرگ، تست‌نویسی رو جدی نگرفتیم. نه تنها تیم، بلکه بیشتر بچه‌ها اصلاً تسلط کاملی هم روی تست‌نویسی نداشتن. به عنوان یه تیم فنی همیشه فکر می‌کردیم که هر چی سریع‌تر پیش بریم و پروژه رو تموم کنیم، بهتره. درسته که پروژه بزرگ بود، ولی چون فکر می‌کردیم وقت نداریم، تست‌نویسی رو کنار گذاشتیم. نتیجه؟ هر بار که یه آپدیت جدید می‌دادیم، به جای اینکه فقط یه مشکل رو حل کنیم، یه عالمه مشکل دیگه هم از دلش بیرون می‌اومد!

از اونجایی که ردیابی خطاها تو محیط پروداکشن یه مصیبت عظمایی که همه شما تجربه‌شو داشتین، این وضعیت برامون تبدیل به یه درس عبرت بزرگ شد. حس کردیم که این اشتباه، نه تنها کیفیت پروژه رو پایین آورد، بلکه زمان زیادی از تیم رو هم تلف کرد.