كيفية اختبار استخدام بيانات وهمية على دائرة الرقابة الداخلية

من أجل توفير برامج عالية الجودة وتجنب الانحدار ، يعد تنفيذ اختبار الوحدة أمرًا ضروريًا لكل تطبيق iOS.
الكائنات الساخرة هي أسلوب في اختبار الوحدة يقوم بإنشاء كائنات مزيفة باستخدام نفس واجهات برمجة التطبيقات مثل تلك الحقيقية.
هذه المقالة أكثر ذكاءً لتزويدك بأفضل الممارسات حول كيفية استخدام البيانات المزيفة وكتابة اختبارات الوحدات لأكثر السيناريوهات التي تحدث على تطبيقات iOS.

عند كتابة اختبارات الوحدة ، يجب أن نتجنب دائمًا تغيير البيانات الحقيقية لهدف التطبيق وبدلاً من ذلك نستخدم البيانات المزيفة لأغراض الاختبار فقط.

ستناقش الأجزاء التالية كيفية كتابة الاختبارات باستخدام بيانات مزيفة لواجهة برمجة تطبيقات iOS شائعة الاستخدام.

افتراضيات المستخدم

في تطوير البرمجيات ، من الممارسات الجيدة دائمًا تقليل تبعية الكائنات. يجب حقن التبعيات في أفضل الحالات في الفئات التي تستخدمها.

ولكن إذا تحققنا من سيناريوهات تطوير iOS الحقيقي ، فإن كل مشروع يستخدم UserDefaults تقريبًا عن طريق استدعاء واجهة برمجة التطبيقات (API) الخاصة به مباشرةً لتخزين أو استرداد أي بيانات.

لذلك سنحاول تقديم حل عملي لاختبار UserDefaultsrather بدلاً من استخراج API الخاص به مع البروتوكولات.

يمكننا إنشاء وظيفتين جديدتين في UserDefaults

من الممارسات الجيدة دائمًا عدم تغيير بيانات التطبيق من هدف اختبار الوحدة ، لذلك يجب علينا إنشاء مكان آخر لحفظ بيانات المستخدم لهدف الاختبار.

في هذه الحالة ، نقوم بتهيئة كائن جديد من UserDefaults باستخدام suiteName - testDefaults أنه مستقل تمامًا عن UserDefaults القياسي.

دعنا نحاول كتابة اختبار بسيط يستخدم UserDefaults

نظرًا لأن هذه البيانات تُستخدم أساسًا للاختبار فقط ، فيجب أن نتجنب ترك تلك البيانات معلقة في ملفات التطبيق الخاصة بنا ، وبالتالي ، فإننا ننشئ وظيفة مسؤولة عن إسقاط وحدة التخزين هذه بعد الانتهاء من الاختبار.

سيكون أفضل مكان لتطهير هذه البيانات ، بطبيعة الحال ، هو وظيفة المسيل للدموع في فئة اختبار الوحدة.

كائنات Singelton

تُستخدم كائنات Singletons بشكل كبير على iOS على العديد من واجهات برمجة التطبيقات ، ويمكننا العثور عليها على NSFileManager و NSApplication و UIApplication وفي العديد من الأماكن الأخرى.

تعد معرفة كيفية اختبار المفردات أمرًا مفيدًا لمطوري iOS.

في مثالنا ، سوف نستخدم إطار عمل iAd apple من التفاح. سننشئ ملفًا للحصول على استجابة JSON محلية بدلاً من بيانات حقيقية عند طلب تفاصيل إسناد الإعلان.

هناك ميزة لطيفة في نظام التشغيل iOS وهي أن الإضافات السريعة لا تسمح لنا بإضافة وظائف جديدة لواجهة برمجة تطبيقات محددة مسبقًا ولكن أيضًا جعلها متوافقة مع بروتوكولاتنا المخصصة.

دعونا نحدد بروتوكول AdvertismentClient

بعد ذلك ، نلتزم بهذا البروتوكول من خلال ADClient الافتراضي وعميل الإعلان المزيف مثل التالي

ثم نغير التبعية لأي منهما

var var adClient: AdvertismentClient = ADClient.shared ()

أو

var adClient: AdvertismentClient = MockAdClient ()

واستخدامها على النحو التالي

وبهذه الطريقة ، يمكننا أن نقرر بسهولة متى نستخدم البيانات الحقيقية ومتى يتم اختبارها ، وهذا يتوقف على ما إذا كنا نختبر الوحدة أو نطلب واجهة برمجة التطبيقات من هدف التطبيق المباشر لدينا.

البيانات الأساسية

لا تزال البيانات الأساسية تستخدم بدرجة كبيرة في نظام التشغيل iOS للتخزين المؤقت للبيانات. يمكن اختبار كيانات البيانات الأساسية تكون صعبة. سنشرح أدناه ممارسة جيدة لكل من تنظيم خدمات البيانات الأساسية والبيانات المزيفة.

بشكل عام في معظم الحالات ، من الجيد دائمًا إنشاء فئة خدمة تكون مسؤولة عن جلب وكتابة بيانات محددة في قاعدة البيانات ، بدلاً من استخدام رمز البيانات الأساسي في جميع أنحاء المشروع.

هذا بشكل رئيسي له فائدتان:

  • يفصلك عن قاعدة البيانات الأساسية المستخدمة ، إذا كنت ترغب في استبدال البيانات الأساسية بأية قاعدة بيانات أخرى في المستقبل سيكون عليك إجراء تغييرات في فصل واحد فقط.
  • من خلال القيام بذلك ، يمكننا تحديد أي من CoreDataStack سيستخدم بسهولة أو أي إعداد آخر قد نحتاجه في بعض الأطر الأخرى.

سنقوم بإنشاء بروتوكول CoreDataStack وبعد ذلك اثنين من CoreDataStacksthat يتوافق مع هذا البروتوكول واحد MainCoreDataStack و MockCoreDataStack واحد.

يمكن حينئذٍ تهيئة خدمة قاعدة البيانات الخاصة بنا بواسطة أيٍّ منهما وفقًا لما إذا كنا نستخدمها على هدف التطبيق لدينا أو على هدف اختبار الوحدة.

سيكون لدينا كومة البيانات الأساسية الرئيسية لدينا الإعداد الافتراضي مثل التالي

عند اختبار الوحدة دائمًا ، يجب أن نتجنب تغيير حالة الكائنات "الحقيقية" الحالية عند اختبارها.

لذلك ، عندما نريد إنشاء كيانات بيانات أساسية مزيفة ، يجب أن يكون لدينا مخزن ثابت منفصل واستخدام تكوين نوع متجر في الذاكرة حتى لا يتم حفظ التغييرات التي تم إجراؤها على القرص وسيتم فصلها تمامًا عن البيانات المستمرة حاليًا.

سنكون الآن قادرين على إنشاء خدمة قاعدة البيانات الخاصة بنا والتي تتم تهيئتها بشكل افتراضي مع MainCoreDataStack.

وفي فصل الاختبار الخاص بنا ، يمكننا التهيئة باستخدام مكدس البيانات المزيف

يمكننا الآن كتابة بعض الاختبارات البسيطة على النحو التالي:

باستخدام هذا النهج ، يمكننا بسهولة اختبار DatabaseService دون التأثير على أي من البيانات المخزنة بواسطة هدف التطبيق.

طلبات الشبكة

عند اختبار طبقة الشبكة ، يمكننا استخدام النهج الموجه للبروتوكول لإنشاء بروتوكول والالتزام به من قبل كل من NetworkService و MockNetworkService الحقيقي وبعد ذلك حقن التبعيات إما باستخدام خدمة حقيقية أو ساخرة.

في هذه المقالة ، على الرغم من أننا سنستخدم مكتبة مفتوحة المصدر لطيفة جدًا تسمى OHHTTPStubs والتي ستتعامل مع السخرية والعناد بشكل أفضل.

الشيء الجيد في هذه المكتبة هو أنها تعمل بشكل رائع مع مكتبة شبكة iOS الشهيرة Alamofire.

يعد طلب Stubbing Network أمرًا سهلاً مع OHHTTPStubs ، حيث يمكنك استبدال أي استجابة لمسار أو مضيف معين عن طريق إعطاء استجابة مخصصة مع القاموس.

بعد ذلك ، سيعود كل طلب ينتقل من التطبيق إلى عنوان URL التالي إلى ردنا المخصص بدلاً من ذلك.

اسمح للمهامURL = URL (سلسلة: "https://jsonplaceholder.typicode.com/todos")!

الأمر الرائع أيضًا في الاستجابات المخصصة هو أنه يمكنك بسهولة اختبار ما إذا كان يتم معالجة حالات الخطأ والحافة بشكل صحيح من خلال إرجاع خطأ في الاستجابة.

يعد إنشاء القاموس للاستجابة يدويًا ميزة رائعة ، ولكن عندما نريد إرجاع بيانات JSON كبيرة تحتوي على الكثير من الخصائص ، فقد تصبح غير قابلة للتطبيق وبالكاد يمكن صيانتها في فصول الاختبار لدينا.

في هذه الحالات ، يمكننا استخدام ملف JSON لإيقاف الاستجابة كما يلي.

الآن في كل مرة يرسل فيها تطبيقنا الطلب ، سنحصل على الرد من الملف myResponse.json الذي قمنا بحفظه في ملفاتنا.

يجب أن نتذكر رغم ذلك تجنب حفظ المعلومات الحساسة في ملفات JSON هذه لأنه إذا قمنا بشحن هذه الملفات مع التطبيق ، فيمكن مشاهدتها بسهولة.

يمكنك التحقق من مقالتي حول موضوع الأمان لمزيد من المعلومات.

فى الختام

وحدة اختبار طلبنا أمر لا بد منه إذا كنا نريد تجنب الانحدار إلى أقصى حد ممكن ، وكذلك محاولة تقديم تطبيق لا تشوبه شائبة.

في هذه المقالة ، ناقشنا كيفية توفير اختبار للحالات الشائعة التي تحدث أثناء تطوير iOS.

ناقشنا كيفية اختبار UserDefaults و Singeltons والبيانات الأساسية وطلبات الشبكة.

إذا كنت تحب هذه المقالة ، فتأكد من التصفيق لإظهار دعمك.

اتبعني لعرض المزيد من المقالات التي يمكن أن تنقل مهارات مطور iOS الخاص بك إلى المستوى التالي.

إذا كان لديك أي أسئلة أو تعليقات فلا تتردد في ترك ملاحظة هنا أو مراسلتي عبر البريد الإلكتروني على arlindaliu.dev@gmail.com.