Improved Persian translation of the 'testing' section

README-ir.md

@@ -30,7 +30,7 @@
   - [ایجاد محیط‌های توسعه‌ی یکپارچه (Consistent Dev Environments)](#consistent-dev-environments)
   - [وابستگی‌های یکسان و هماهنگ (Consistent Dependencies)](#consistent-dependencies)
 - [وابستگی‌ها (Dependencies)](#dependencies)
-- [تست کردن/Testing](#testing)
+- [تست کردن (Testing)](#testing)
 - [ساختار و نام‌گذاری/Structure and Naming](#structure-and-naming)
 - [سبک کدنویسی/Code style](#code-style)
   - [برخی از دستورالعمل‌های code style](#code-style-check)
@@ -380,55 +380,55 @@ _چرا:_
 
 <a name="testing"></a>
 
-## 5. تست کردن/Testing
+## 5. تست کردن (Testing)
 
 <p align="right">
   <img src="/images/testing.png" alt="testing" width="128" height="128">
 </p>
 
-- در صورت نیاز، یک environment به نام `test` (برای حالت تست) ایجاد کنید.
+- در صورت نیاز، یک محیط تست (test environment) ایجاد کنید.
 
 _چرا:_
 
-> گاهی تست end to end در حالت `production` ممکن است کافی به نظر برسد، اما در موارد خاص نیاز به محیط تست جداگانه‌ای وجود دارد. مثلاً ممکن است نخواهید اطلاعات تحلیلی در حالت `production` فعال شود و داشبورد افراد را با داده‌های تست آلوده کنید. (توضیحات مترجم: چون داده‌های تستی ممکن است اطلاعات واقعی را تحت تأثیر قرار دهد، مثلا باعث شلوغی و ایجاد داده‌های غیرضروری شوند و یا مانع از درک دقیق اطلاعات واقعی توسط کاربران یا تیم تحلیل شوند.) مثال دیگر این است که ممکن است API شما در حالت تولید محدودیت‌ تعداد درخواست (rate limit) داشته باشد و پس از تعداد مشخصی درخواست، فراخوانی APIها توسط تست را مسدود کند.
+> در برخی پروژه‌ها، تست End-to-End در محیط `production` ممکن است کافی به نظر برسد، اما مواقعی پیش می‌آید که یک محیط تست جداگانه ضروری است. به‌عنوان مثال، ممکن است مایل نباشید در حالت `production` داده‌های آزمایشی ایجاد کنید یا اطلاعات تحلیلی کاربران را تحت تأثیر قرار دهید. همچنین ممکن است API شما در حالت `production` دارای محدودیت تعداد درخواست (rate limit) باشد که اجرای تست‌ها را در آن دشوار کند.
 
-- فایل‌های تست خود را در کنار ماژول‌های مورد آزمایش با استفاده از الگوی نام‌گذاری خاصی `*.test.js` یا `*.spec.js` قرار دهید، مانند `moduleName.spec.js`.
+- فایل‌های تست را در کنار فایل اصلی قرار دهید. با استفاده از الگوی نام‌گذاری خاصی مانند `*.test.js` یا `*.spec.js`، مانند `moduleName.spec.js`.
 
 _چرا:_
 
-> برای پیدا کردن یک تست واحد، در ساختار پوشه‌ها جستجو و پیمایش نکنید. [توضیحات بیشتر ...](https://hackernoon.com/structure-your-javascript-code-for-testability-9bc93d9c72dc)
+> تا به‌راحتی قابل یافتن باشند و نیاز به جستجو و پیمایش در ساختار پروژه نباشد. ([توضیحات بیشتر ...](https://hackernoon.com/structure-your-javascript-code-for-testability-9bc93d9c72dc))
 
-- برای جلوگیری از سردرگمی، فایل‌های تست اضافی خود را پر یک پوشه جداگانه قرار دهید.
+- ممکن است برخی از تست‌ها به فایل‌های پیاده‌سازی خاصی مربوط نباشد، دراین‌صورت آن‌ها را در یک دایرکتوری مجزا قرار دهید.
 
 _چرا:_
 
-> برخی از فایل‌های تست مستقیماً به فایل پیاده‌سازی خاصی مرتبط نیستند. باید این فایل‌ها را در پوشه‌ای قرار دهید که احتمالاً توسط سایر توسعه‌دهندگان به راحتی یافت شود: پوشه `__test__`. این نام `__test__` هم اکنون یک استاندارد است و توسط اکثر فریم‌ورک‌های تست جاوااسکریپت تشخیص داده می‌شود.
+> ممکن است برخی از تست‌ها به فایل‌های پیاده‌سازی خاصی مربوط نباشد، دراین‌صورت آن‌ها را در یک دایرکتوری مجزا مانند `__test__` قرار دهید. این نام‌گذاری `__test__` هم اکنون یک استاندارد است و در اکثر فریم‌ورک‌های تست جاوااسکریپت نیز شناخته شده می‌باشند.
 
-- کد قابل تست بنویسید، از اثرات جانبی (side effect) خودداری کنید، اثرات جانبی را جدا کنید، و توابع خالص (pure functions) بنویسید.
+- کدهایی بنویسید که منطقی واضح داشته باشند و بتوان آن‌ها را مستقل از هر عامل خارجی (side effect) آزمایش کرد و نتیجه یکسان بدهد (pure functions).
 
 _چرا:_
 
-> هر بخش از منطق کسب‌وکار (business logic) باید به صورت مستقل و جداگانه مورد آزمایش و تست قرار گیرد تا مطمئن شوید که هر قسمت به درستی کار می‌کند. باید "تأثیر عوامل تصادفی یا فرآیندهای غیرقابل‌پیش‌بینی را در کد به حداقل برسانید" [توضیحات بیشتر ...](https://medium.com/javascript-scene/tdd-the-rite-way-53c9b46f45e3)
+> هر بخش از منطق کسب‌وکار (business logic) باید به صورت مستقل و جداگانه مورد آزمایش و تست قرار گیرد تا مطمئن شوید که آن بخش‌ها به درستی کار می‌کند. باید "تأثیر عوامل تصادفی یا فرآیندهای غیرقابل‌پیش‌بینی را در کد به حداقل برسانید" [توضیحات بیشتر ...](https://medium.com/javascript-scene/tdd-the-rite-way-53c9b46f45e3)
 
-> یک تابع خالص (pure function) تابعی است که همیشه برای ورودی یکسان، خروجی یکسانی را باز می‌گرداند. برعکس، یک تابع ناخالص (impure function) تابعی است که ممکن است اثرات جانبی داشته باشد یا برای تولید یک مقدار به شرایط خارجی وابسته باشد، که این امر باعث می‌شود کمتر قابل پیش‌بینی باشد. [توضیحات بیشتر ...](https://hackernoon.com/structure-your-javascript-code-for-testability-9bc93d9c72dc)
+> یک تابع خالص (pure function) تابعی است که همیشه برای ورودی یکسان، خروجی یکسانی را باز می‌گرداند. برعکس، یک تابع ناخالص (impure function) تابعی است که ممکن است اثرات جانبی داشته باشد یا برای تولید یک مقدار به شرایط خارجی وابسته باشد، که این امر باعث می‌شود کمتر قابل پیش‌بینی باشد. [توضیحات بیشتر ...](https://hackernoon.com/structure-your-javascript-code-for-testability-9bc93d9c72dc)
 
-- از یک static type checker استفاده کنید
+- از یک Static Type Checker استفاده کنید
 
 _چرا:_
 
-> گاهی ممکن است به یک Static type checker نیاز داشته باشید. این ابزارها، سطحی از قابلیت اطمینان را برای کد شما به ارمغان می‌آورند. [توضیحات بیشتر ...](https://medium.freecodecamp.org/why-use-static-types-in-javascript-part-1-8382da1e0adb)
+> ابزارهایی مانند Flow یا TypeScript می‌توانند با بررسی نوع (Type) متغیرها و توابع، سطح اطمینان کد را بالا ببرند و از بروز خطاهای پیش‌بینی‌نشده جلوگیری کنند. ([توضیحات بیشتر ...](https://medium.freecodecamp.org/why-use-static-types-in-javascript-part-1-8382da1e0adb))
 
-- قبل از آنکه درخواست pull request به برنچ `develop` را ارسال کنید، تست‌ها را به‌صورت locally اجرا کنید.
+- پیش از آنکه درخواست pull request به برنچ `develop` ارسال کنید، تست‌ها را به‌صورت locally اجرا کنید.
 
 _چرا:_
 
-> قطعاً نمی‌خواهید کسی باشید که باعث شکست فرایند بیلد برنچ آماده‌ی production شده است. تست‌های خود را پس از `rebase` و پیش از ارسال به شاخه feature-branch به مخزن ریموت اجرا کنید.
+> همیشه پیش از ارسال Pull Request، تست‌ها را در سیستم محلی (local) خود اجرا کنید و مطمئن شوید که هیچ موردی باعث شکست فرآیند Build در برنچ `develop` یا `production` نمی‌شود.
 
-- تست‌های خود را از جمله دستورالعمل‌های مربوطه در بخش مناسب فایل `README.md` پروژه را مستندسازی کنید.
+- در فایل `README.md` (یا هر مستند دیگری که پروژه استفاده می‌کند)، نحوه اجرای تست‌ها و نیازمندی‌های مرتبط را توضیح دهید.
 
 _چرا:_
 
-> این مستندات مانند یک یادداشت راهنما است که برای توسعه‌دهندگان دیگر، کارشناسان DevOps، یا تیم تضمین کیفیت (QA) و هر کسی که با کد شما کار می‌کند، مفید خواهد بود.
+> این مستندات مانند یک یادداشت راهنما است که برای سایر اعضای تیم، کارشناسان DevOps، یا تیم تضمین کیفیت (QA) و هر کسی که با کد شما کار می‌کند، مفید خواهد بود.
 
 <a name="structure-and-naming"></a>