فصل یازدهم: تست نرم‌افزار در مقیاس گوگل

تا حالا به این فکر کرده‌اید که چرا وقتی کدهای جدیدی به یک برنامه اضافه می‌کنید، مدام نگران هستید که مبادا بخش دیگری از سیستم از کار بیفتد؟ چطور ممکن است شرکتی با مقیاس گوگل هر روز تغییرات فراوانی را منتشر کند بدون اینکه کل سیستم فرو بریزد؟

این موضوع در کتاب «مهندسی نرم‌افزار در گوگل» اثر تیتوس وینترز، تام مانشریک و هایروم رایت بررسی شده است و فصل یازدهم آن نشان می‌دهد که چگونه تست خودکار، کلید اصلی ایجاد اعتماد به تغییرات در نرم‌افزارهای مدرن است.

در روزهای اولیه، پروژه سرور وب گوگل با مشکلات بزرگی روبه‌رو بود زیرا تیم‌ها به هوش برنامه‌نویسان تکیه می‌کردند و تست خودکار نداشتند. راه‌حل این بود که سیاست تست‌های خودکار توسعه‌دهنده‌محور اجباری شود، که این کار توانست تعداد انتشارهای اضطراری را به شدت کاهش دهد. معامله‌ای که اینجا انجام می‌شود صرف زمان اولیه برای نوشتن تست در برابر خریدن آرامش خاطر و کاهش چشمگیر باگ‌ها در طول عمر نرم‌افزار است؛ مثلاً نوشتن یک تست واحد (Unit Test) برای بررسی یک تابع ریاضی ساده که از بروز خطاهای آتی جلوگیری می‌کند.

چالش دیگر این است که با رشد کد بیس، تست‌ها ممکن است کند و غیرقابل اعتماد شوند. گزینه‌های پیش رو شامل نوشتن تست‌های سیستم‌محور بزرگ یا تفکیک آن‌ها بر اساس اندازه و دامنه است. نویسندگان توضیح می‌دهند که گوگل تست‌ها را بر اساس میزان منابع مصرفی به سه دسته کوچک، متوسط و بزرگ دسته‌بندی می‌کند. به عنوان مثال، یک تست کوچک (Small Test) نباید به شبکه یا دیتابیس وصل شود تا بتواند با سرعتی نزدیک به توانایی پردازنده مرکزی اجرا شود.

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

پیچیدگی معماری و وابستگی‌های زیاد همواره مانع نوشتن تست‌های تمیز است. گزینه‌های موجود شامل استفاده از کدهای ماژولار یا پناه بردن به ابزارهای شبیه‌ساز است. استفاده از جایگزین تست (Test Double) به مهندسان اجازه می‌دهد وابستگی‌های سنگین مثل پایگاه داده را با نمونه‌های سبک درون حافظه جایگزین کنند تا تست‌ها سریع و ایزوله باقی بمانند.

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

امیدوارم از این اپیزود لذت برده باشید و نگاه تازه‌ای به اهمیت تست‌نویسی پیدا کرده باشید.