---
title: "محاكاة استجابات الخادم باستخدام Postman على Android"
description: "طريقة سهلة لاختبار تطبيقكم في جميع السيناريوهات باستخدام Postman Mock Server"
canonical: https://oozou.com/ar/blog/mocking-server-response-data-with-postman-on-android-61
locale: ar
date: 2020-06-26
author: "OOZOU Team"
---

# محاكاة استجابات الخادم باستخدام Postman على Android

> طريقة سهلة لاختبار تطبيقكم في جميع السيناريوهات باستخدام Postman Mock Server

Published: 2020-06-26 · Author: OOZOU Team (Engineering) · 8 min read

بصفتنا مطوّري تطبيقات جوال، علينا التعامل مع كل استجابة تأتي من الخادم لنتأكد من أن تطبيقاتنا الجميلة تعمل كما ينبغي.

ولاختبار كل استجابة من الخادم، نضطر غالبًا إلى إنشاء بيانات وهمية (mock data) محليًا داخل المشروع نفسه. وهذا يستهلك وقتًا طويلًا، خاصة أننا نحتاج إلى تعديل هذه البيانات كلما غيّر الخادم استجاباته. وإذا كان لدينا تطبيق Android وآخر iOS وثالث للويب، فسيتضاعف هذا العمل ثلاث مرات.

مع Postman Mock Server يمكنكم اختبار التطبيق بسهولة، دون أن تطلبوا من فريق الـ backend تعديل الاستجابة لكل حالة اختبار ممكنة، ودون انتظار فريق QA لساعات (T_T). **دورات اختبار أقصر وجودة اختبار أعلى! \\0/**

> _بمجرد أن يصبح لديكم mock server، يمكنكم التركيز على اختبارات الانحدار (regression) لواجهة المستخدم._

سأوضح لكم في هذا المقال كيف تستخدمون Postman كـ mock server يسهل فيه تغيير الاستجابة، لتتمكنوا من اختبار واجهة المستخدم بشكل متسق.
سنجلب [بعض مستودعات GitHub العامة](https://developer.github.com/v3/repos/#list-public-repositories) ونستخدم المفتاحين **name** و **description** فقط في هذا المشروع التجريبي.

**ما هو Postman؟**

Postman منصة تعاون لتطوير واجهات API. تبسّط ميزاته كل خطوة من خطوات بناء الـ API وتسهّل التعاون، لتبنوا واجهات API أفضل وبسرعة أكبر. [www.postman.com](https://www.postman.com/)

**كيف تنشئون mock server باستخدام Postman؟**

أفترض أنكم نزّلتم Postman وسجّلتم الدخول. وإن لم تفعلوا، يمكنكم تنزيله [من هنا](https://www.postman.com/)

1. أنشئوا mock server جديدًا بالنقر على New أعلى اليسار واختيار Mock Server
2. أضيفوا المسار **/repositories** ونص الاستجابة (Response Body) **"Mock body sample"**
3. اختاروا اسمًا للـ mock server الجديد!
4. أنشئوا الـ mock server. سترون رابط الـ mock الخاص بكم بهذا الشكل.
5. وسّعوا مجموعة **"Github Mock Server"** لتروا طلب الـ API، ولا تنسوا تغيير الـ environment إلى **"Github Mock Server"** أعلى اليمين، ثم جرّبوا استدعاء الـ mock server بالنقر على Send. **وها هو!!!!**

> **تهانينا!** أصبح لديكم mock server خاص بكم!!!

**حان وقت إضافة بعض السحر إلى الـ mock server!**

من هنا يمكنكم تغيير الاستجابة في هذا المشروع التجريبي. سنضيف بيانات الاستجابة التالية إلى الـ mock server

```json
[
  {
    "id": 1,
    "name": "Android-Test1",
    "description": "Android-Test1 description"
  },
  {
    "id": 2,
    "name": "Android-Test2",
    "description": "Android-Test2 description"
  },
  {
    "id": 3,
    "name": "Android-Test3",
    "description": "Android-Test3 description"
  },
  {
    "id": 4,
    "name": "Android-Test4",
    "description": "Android-Test4 description"
  }
]
```

1. يمكنكم تحديث الاستجابة الافتراضية بالنقر على Examples واختيار Default.
2. بعد ذلك يمكنكم تغيير الاستجابة ورمز الحالة (status code)، واحرصوا على إضافة **"Content-Type: application/json"** إلى ترويسات الاستجابة (response headers) لتعريف مستهلكي الـ API بصيغة الاستجابة.
3. احفظوا الإعدادات واستدعوا الـ API مرة أخرى. يُفترض أن تروا بيانات الاستجابة بهذا الشكل:

> **رائع!** انتهيتم من إعداد الـ mock server!

> **والآن**، لنجرّب الـ mock server في مشروع Android.

**تحتاجون إلى build type خاص بالـ mock لفصل رابط الـ mock server عن بيئة الإنتاج.**

هناك طرق كثيرة لفعل ذلك. وهذه إحداها، وتعمل جيدًا مع وحدة Android library ووحدة Android application على حد سواء.
1. أنشئوا ملف **common-properties.gradle** واحفظوه في جذر المشروع. بهذه الطريقة يمكنكم إعادة استخدام الإعدادات في جميع الوحدات.

```gradle
android.buildTypes {
    mock {
        buildConfigField "String", "BASE_API_URL", "\"https://c77b2784-b60b-491b-af7e-273c356ef4a2.mock.pstmn.io\""
    }
    debug {
        buildConfigField "String", "BASE_API_URL", "\"https://api.github.com/\""
    }
    release {
        buildConfigField "String", "BASE_API_URL", "\"https://api.github.com/\""
    }
}
```

2. استوردوا **common-properties.gradle** في ملف **app/build.gradle**

```gradle
apply from '../<strong>common-properties</strong>.gradle'
...
android {
...
```

3. أعيدوا المزامنة (Re-sync) وغيّروا الـ Build variant إلى mock ثم أعيدوا بناء المشروع. وبعد نجاح البناء سترون **BASE_API_URL** في ملف BuildConfig الذي يُنشأ تلقائيًا.
4. الآن يمكنكم الوصول إلى رابط الـ API الأساسي من أي مكان في تطبيقكم.

```kotlin
BuildConfig.BASE_API_URL
```

**تشغيل تطبيق Android على بيئة الإنتاج!**

بهذه الطريقة لا يمكنكم اختبار سوى حالتين: نجاح استجابة خادم الـ API، وانقطاع الاتصال بالإنترنت.

**أما الآن، فشغّلوه مع الـ mock server!**

مع الـ mock server يمكنكم اختبار حالات أكثر بكثير

يمكنكم الاطلاع على الكود التجريبي هنا: [https://github.com/arohim/SampleMockServerWithPostman](https://github.com/arohim/SampleMockServerWithPostman)

# لماذا نحاكي استجابات الخادم في تطوير Android؟

تقدّم محاكاة استجابات الخادم أثناء تطوير تطبيقات Android مزايا عديدة:

- **تسريع التطوير**: يستطيع المطوّرون العمل على وظائف التطبيق دون انتظار اكتمال واجهة API الخاصة بالـ backend أو استقرارها.
- **تسهيل اختبار الحالات الحدّية**: تتيح البيانات الوهمية محاكاة طيف واسع من استجابات الخادم، منها النجاح والأخطاء والحالات الحدّية مثل انتهاء المهلة (timeout) أو الحمولات الكبيرة.
- **التطوير دون اتصال**: تتيح لكم مواصلة التطوير حتى في غياب خادم يعمل أو اتصال بالإنترنت.
- **تقليل التبعيات**: تقلّل الاعتماد على فرق الـ backend، فيتقدّم العمل على الـ frontend والـ backend بالتوازي.

توضّح هذه الفوائد للقرّاء لماذا يُعدّ Postman أداة قيّمة في عملية تطوير تطبيقات Android.

# ميزات متقدمة في Postman Mock Server

1.**استجابات ديناميكية مع الـ Mock Server**

- يتيح Postman تعريف استجابات ديناميكية باستخدام متغيرات الـ mock server. ويمكن لهذه المتغيرات محاكاة ظروف مختلفة مثل بيانات خاصة بمستخدم معيّن أو إصدارات مختلفة من الـ API.
- مثال: استخدموا `{{$randomInt}}` لإرجاع رقم عشوائي في الاستجابة، لمحاكاة بيانات ديناميكية من الخادم.

2.**ضبط تأخير الاستجابة**

- يتيح الـ mock server ضبط تأخير للاستجابات، وهذا مفيد لاختبار تعامل تطبيقكم مع اتصالات الشبكة البطيئة.
- مثال: أضيفوا تأخيرًا قدره 500ms لمحاكاة استجابة خادم بطيئة.

3.**إدارة إصدارات استجابات الـ API**

- يتيح Postman إدارة إصدارات متعددة من الاستجابات الوهمية. وهذا مفيد خصوصًا إذا كانت واجهة الـ API تتطور مع الوقت، إذ يمكنكم اختبار تطبيقكم مع إصدارات مختلفة منها دون تعديل الـ backend.

# دمج Postman Mock Server في سير عمل تطوير Android

**1\. اختبار التعامل مع أخطاء الشبكة**

- استخدموا Postman لمحاكاة أعطال الشبكة، مثل 500 Internal Server Error أو 404 Not Found. وهذا يضمن أن يتعامل تطبيقكم مع هذه السيناريوهات بسلاسة ويحافظ على تجربة مستخدم جيدة.

**2\. محاكاة البيانات المقسّمة إلى صفحات (Pagination)**

- حاكوا بيانات مقسّمة إلى صفحات لاختبار تعامل تطبيقكم مع القوائم أو الموجزات. على سبيل المثال، أنشئوا استجابات متعددة لـ page=1 وpage=2 وهكذا، لمحاكاة تحميل بيانات إضافية.

**3\. الاختبار في بيئات متعددة**

- يمكن ضبط الـ mock servers في Postman لبيئات مختلفة (مثل staging وproduction). استخدموا متغيرات البيئة في Postman لاختبار سلوك تطبيقكم مع إعدادات مختلفة.

# 

# التحديات الشائعة وحلولها

1. **دمج رابط الـ Mock Server**    - **المشكلة**: التبديل يدويًا بين الـ mock server والـ endpoints الخاصة بالإنتاج قد يؤدي إلى أخطاء.
    - **الحل**: استخدموا build variants أو ملفات إعدادات في مشروع Android للتبديل بين روابط الـ mock server وروابط الإنتاج.
2. **اختبار المحتوى الديناميكي**    - **المشكلة**: تُرجع الـ mock servers عادة استجابات ثابتة قد لا تغطي جميع السيناريوهات الواقعية.
    - **الحل**: استخدموا ميزات كتابة السكربتات في Postman لإضافة منطق يولّد استجابات ديناميكية، مثل توليد بيانات عشوائية أو إرجاع استجابات بحسب معاملات الطلب.
3. **تحديات المصادقة**    - **المشكلة**: قد يكون اختبار استدعاءات الـ API التي تتطلب مصادقة عبر الـ mock servers معقدًا إذا كان التطبيق يحتاج إلى tokens.
    - **الحل**: حاكوا الـ endpoint الخاص بالمصادقة ليُرجع token ثابتًا، يمكن استخدامه بعد ذلك في الطلبات اللاحقة إلى الـ mock server.
# نصائح لتصحيح الأخطاء في Postman Mock Server

1. **افحصوا سجلات الـ Mock Server**:
    -   يوفّر Postman سجلات مفصّلة لنشاط الـ mock server. استخدموها لتتبّع الطلبات والاستجابات أثناء الاختبار.
2. **تحقّقوا من صحة JSON Schema**:
    -   استخدموا ميزة التحقق من JSON schema المدمجة في Postman لضمان توافق الاستجابات الوهمية مع عقد الـ API المتوقع.
3. **اختبروا سيناريوهات الأخطاء بدقة**:
    -   حاكوا الحالات الحدّية، مثل المدخلات غير الصالحة أو المعاملات المفقودة أو الحمولات الكبيرة، لاكتشاف المشكلات المحتملة في منطق معالجة الأخطاء في تطبيقكم.

# أفضل الممارسات في المحاكاة باستخدام Postman

1. **وثّقوا سيناريوهات المحاكاة**:
    -   احتفظوا بتوثيق واضح لجميع سيناريوهات المحاكاة، بما فيها أمثلة الطلبات والاستجابات. وهذا يضمن أن يفهم الفريق كله الـ mock server ويستخدمه بفاعلية.
2. **استخدموا قواعد تسمية متسقة**:
    -   سمّوا مجموعات الـ mock والاستجابات بأسماء تعكس الغرض منها (مثل User Login - Success وUser Login - Invalid Credentials).
3. **ادمجوا اختبارات المحاكاة في CI/CD**:
    -   استخدموا أداة Newman CLI من Postman لتشغيل الاختبارات على الـ mock server ضمن خط التكامل المستمر، لضمان سلوك متسق عبر جميع الإصدارات.

# الخلاصة
1. مع الـ mock server يمكنكم محاكاة أي استجابة وأي رمز حالة تريدون اختباره بسهولة، و**هذا يرفع جودة اختباراتكم.** 2.  لا تحتاجون إلى إنشاء بيانات وهمية داخل مشاريع الـ front-end، إذ يمكنكم استخدام الـ mock server وإعادة استخدامه **في أي مكان**.
3. يصبح لديكم **مصدر واحد للمعلومات.**
4. يسهل التواصل بين فريقَي الـ Back-end والـ Front-end بفضل أداة ممتازة من Postman لإعداد توثيق الـ API.
5. يستطيع المختبرون تغطية **جميع حالات الاختبار المتوقعة.** 6.  والأهم من ذلك أن هذا **يسرّع التطوير**، لأنكم لن تضطروا بعد الآن إلى انتظار فريق الـ Back-end لإعداد بيانات وهمية للاختبار.

شكرًا لقراءة مقالي! إن كانت لديكم اقتراحات أخرى فشاركوني بها، فأنا أحب تعلّم خيارات جديدة (^_^)

المصادر

- [https://learning.postman.com/docs/postman/mock-servers/setting-up-mock/](https://learning.postman.com/docs/postman/mock-servers/setting-up-mock/)
- [مراجعة ورشة عمل POST/CON 2018: الـ Mock servers](https://www.youtube.com/watch?v=tXjoya11RAg)

---

Contact OOZOU: hello@oozou.com · +66 2544 0000 · https://oozou.com/ar/contact

More for AI agents: https://oozou.com/llms.txt · every page has a markdown twin at its URL plus ".md"