دربارهٔ این فصل
یادداشتِ همراه نوارتا حالا به این فکر کرده‌اید که چطور می‌توان هزاران تست نرم‌افزاری را در چند دقیقه اجرا کرد، بدون اینکه درگیر خطاهای شبکه یا کندی پایگاه‌داده شد؟ وقتی کدهای ما به سرورهای خارجی یا پایگاه‌های داده وصل می‌شوند، نوشتن تست‌های سریع و قابل‌اعتماد کار ساده‌ای نیست و به ابزارهای خاصی نیاز پیدا می‌کنیم.
کتاب «مهندسی نرم‌افزار در گوگل» نوشتهٔ «تیتوس وینترز، تام مانشریک و هایروم رایت» در فصل سیزدهم به سراغ ابزارهایی می‌رود که نقش بدل را در فیلم‌ها بازی می‌کنند و به ما نشان می‌دهد چطور از آن‌ها برای سرعت‌بخشیدن به توسعه نرم‌افزار بهره ببریم.
نخستین ایده کلیدی در این زمینه، مفهوم جایگزین تست (test double) است. جایگزین تست شیء یا تابعی است که به جای پیاده‌سازی واقعی در تست قرار می‌گیرد تا وابستگی‌های سنگین را شبیه‌سازی کند. مشکل اصلی این است که استفاده از پایگاه‌داده واقعی در تمام تست‌ها کندی و خطاهای غیرقابل‌پیش‌بینی می‌آورد، اما گزینه جایگزین کمک می‌کند تست واحد (unit test) سریع و سبکی داشته باشیم که به شبکه وابستگی ندارد.
دومین ایده مهم، استفاده از نمونه‌های ساختگی یا فیک (fake) است. مشکل اینجاست که پایگاه‌داده واقعی برای تست مناسب نیست، و گزینه‌ها شامل استفاده از کدهای پیچیده یا فیک‌های درون حافظه‌ای می‌شوند. مزیت فیک این است که مانند نسخه واقعی رفتار می‌کند اما سرعت بالایی دارد و معامله اصلی در اینجا هزینه بالای نوشتن و نگهداری فیک توسط تیم سازنده ای‌پی‌آی است. برای مثال، یک سامانه فایل سیستم درون حافظه‌ای می‌تواند جایگزین دیسک سخت شود تا فایل‌ها سریع‌تر خوانده و نوشته شوند بدون اینکه عملیات واقعی دیسک انجام گیرد.
ایده سوم مربوط به چالش‌های استفاده از استابینگ (stubbing) است. مشکل زمانی رخ می‌دهد که تابع هیچ رفتار ذاتی ندارد و ما مجبوریم مقدار بازگشتی آن را با دست در تست تعیین کنیم. معضل بزرگ این است که افراط در این کار باعث شکننده شدن تست‌ها و لو رفتن جزئیات پیاده‌سازی می‌شود. برای مثال، اگر در تست پرداخت بانکی، تمام پاسخ‌های سرور را به صورت دستی و با مقادیر ثابتی کدگذاری کنیم، با کوچک‌ترین تغییر در کد اصلی، تست ما بی‌جهت شکست می‌خورد.
چهارمین ایده کلیدی، بررسی نحوه فراخوانی تابع یا تست تعامل (interaction testing) است. کتاب نشان می‌دهد که اگرچه این روش برای بررسی تعداد دفعات فراخوانی یک متد مفید است، اما افراط در آن تست‌ها را به کدهای حساسی تبدیل می‌کند که با هر تغییر جزئی در ساختار داخلی، به خطا می‌افتند. در این روش، به جای بررسی مقدار خروجی، بررسی می‌کنیم که آیا متد خاصی مثلاً سه بار صدا زده شده است یا خیر، که این کار وابستگی شدیدی به جزئیات پیاده‌سازی ایجاد می‌کند.
پیشنهاد عملی من به شما این است که تا جای امکان از پیاده‌سازی‌های واقعی استفاده کنید و سراغ پیچیدگی‌های غیرضروری نروید. هر زمان که اجرای تست‌ها به دلیل وابستگی‌های خارجی کند شد، به جای وابستگی کورکورانه به فریم‌ورک‌های پیچیده، ساختار کدمان را طوری طراحی کنیم که استفاده از نمونه‌های ساختگی به سادگی میسر شود.
امیدوارم این روایت از نگاه گوگل به ابزارهای تست، دید تازه‌ای برای بهبود کیفیت کدهایتان به شما داده باشد. تا روایتی دیگر، پیروز و پایدار باشید.