تست کردن (Testing) • بلاگ فنی

در صورت نیاز، یک محیط تست (test environment) ایجاد کنید.

چرا

در برخی پروژه‌ها، تست End-to-End در محیط production ممکن است کافی به نظر برسد، اما مواقعی پیش می‌آید که یک محیط تست جداگانه ضروری است. به‌عنوان مثال، ممکن است مایل نباشید در حالت production داده‌های آزمایشی ایجاد کنید یا اطلاعات تحلیلی کاربران را تحت تأثیر قرار دهید. همچنین ممکن است API شما در حالت production دارای محدودیت تعداد درخواست (rate limit) باشد که اجرای تست‌ها را در آن دشوار کند.

فایل‌های تست را در کنار فایل اصلی قرار دهید. با استفاده از الگوی نام‌گذاری خاصی مانند *.test.js یا *.spec.js، مانند moduleName.spec.js.

چرا

تا به‌راحتی قابل یافتن باشند و نیاز به جستجو و پیمایش در ساختار پروژه نباشد. (توضیحات بیشتر … ↗)

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

چرا

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

کدهایی بنویسید که منطقی واضح داشته باشند و بتوان آن‌ها را مستقل از هر عامل خارجی (side effect) آزمایش کرد و نتیجه یکسان بدهد (pure functions).

چرا

هر بخش از منطق کسب‌وکار (business logic) باید به صورت مستقل و جداگانه مورد آزمایش و تست قرار گیرد تا مطمئن شوید که آن بخش‌ها به درستی کار می‌کند. باید “تأثیر عوامل تصادفی یا فرآیندهای غیرقابل‌پیش‌بینی را در کد به حداقل برسانید” توضیحات بیشتر … ↗
یک تابع خالص (pure function) تابعی است که همیشه برای ورودی یکسان، خروجی یکسانی را باز می‌گرداند. برعکس، یک تابع ناخالص (impure function) تابعی است که ممکن است اثرات جانبی داشته باشد یا برای تولید یک مقدار به شرایط خارجی وابسته باشد، که این امر باعث می‌شود کمتر قابل پیش‌بینی باشد. توضیحات بیشتر … ↗

از یک Static Type Checker استفاده کنید

چرا

ابزارهایی مانند Flow یا TypeScript می‌توانند با بررسی نوع (Type) متغیرها و توابع، سطح اطمینان کد را بالا ببرند و از بروز خطاهای پیش‌بینی‌نشده جلوگیری کنند. (توضیحات بیشتر … ↗)

پیش از آنکه درخواست pull request به برنچ develop ارسال کنید، تست‌ها را به‌صورت locally اجرا کنید.

چرا

همیشه پیش از ارسال Pull Request، تست‌ها را در سیستم محلی (local) خود اجرا کنید و مطمئن شوید که هیچ موردی باعث شکست فرآیند Build در برنچ develop یا production نمی‌شود.

در فایل README.md (یا هر مستند دیگری که پروژه استفاده می‌کند)، نحوه اجرای تست‌ها و نیازمندی‌های مرتبط را توضیح دهید.

چرا

این مستندات مانند یک یادداشت راهنما است که برای سایر اعضای تیم، کارشناسان DevOps، یا تیم تضمین کیفیت (QA) و هر کسی که با کد شما کار می‌کند، مفید خواهد بود.