با شمارهٔ موبایل وارد شوید تا بتوانید اشتراک بخرید و در گفتگو شرکت کنید.

خلاصهٔ صوتی کتاب ۱۴۰۵/۰۸/۰۲

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

از کتاب مهندسی نرم‌افزار در گوگل · تیتوس وینترز، تام مانشریک و هایروم رایت

جلد مهندسی نرم‌افزار در گوگل
SHABGOFTAR PORTABLE AUDIOهمراهِ شنیدن
صدایی برای همراه بردنPODCAST · PERSONAL STEREO
شب‌گفتار / دفترچهٔ همراهSHABGOFTAR · LINER NOTES

دربارهٔ این فصل

یادداشتِ همراه نوار
جلد مهندسی نرم‌افزار در گوگلمهندسی نرم‌افزار در گوگلتیتوس وینترز، تام مانشریک و هایروم رایتدیدن همهٔ قسمت‌های این کتاب ←

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

این مبحث از کتاب مهندسی نرم‌افزار در گوگل (Software Engineering at Google) نوشتهٔ تیتوس وینترز، تام مانشریک و هایروم رایت به ما نشان می‌دهد که چطور تست‌های بزرگتر خطرات پنهان سیستم را کاهش می‌دهند.

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

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

مشکل سوم به رفتارهای پیش‌بینی‌نشده زیر بار ترافیک مربوط است. مقیاس‌پذیری (Scalability) و تست‌های عملکردی به هزاران درخواست در ثانیه نیاز دارند. این حجم از ترافیک و رفتارهای نوظهور سیستم هنگام ترکیب سرویس‌ها، در تست‌های کوچک قابل مشاهده نیست. علاوه بر این، قانون هایروم (Hyrum's Law) یادآوری می‌کند که کاربران به تمام رفتارهای قابل مشاهده یک سیستم تکیه می‌کنند، نه فقط به مستندات رسمی آن. بنابراین تست‌های واحد نمی‌توانند همه این ابعاد را بسنجند.

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

پیشنهاد من به شما این است که در پروژهٔ خودتان، هیچ‌وقت به تست‌های واحد اکتفا نکنید و از همان روزهای اول، چند تست یکپارچه‌سازی متصل به هم طراحی کنید تا رفتار واقعی سیستم حفظ شود.

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