كيف وغالبا ما تستخدم
Swift.assert()
في التعليمات البرمجية الخاصة بك؟ أنا بصراحة استخدمها كثيرًا (إذا كانت هذه ممارسة سيئة ، فالرجاء كتابة التعليقات - لماذا هي سيئة؟). في شفرتي ، غالبًا ما ترى مثل هذه المكالمة:
Swift.assert(Thread.isMainThread)
منذ وقت ليس ببعيد ، قررت أنه سيكون من الجيد الاستمرار في مراقبة نتائج هذه المكالمات ، ليس فقط كجزء من إطلاق التطبيق في جهاز محاكاة / جهاز ، ولكن أيضًا من تصرفات المستخدمين الحقيقيين. بالمناسبة ، هنا يمكننا التحدث عن
Swift.precondition()
،
Swift.fatalError()
، وما إلى ذلك ، على الرغم من أنني أحاول تجنبها. قرأت المزيد عن
الأخطاء التي لا يمكن إصلاحها في Swift في هذا المنشور واتضح أنها مفيدة للغاية.
أقرب إلى النقطة:
في رمز وجدت حوالي 300 مثل هذه المكالمات. لم يعمل أي منهم خلال الاختبار المحلي المعتاد ، وكان من دواعي سروري ذلك. لكنني اقترحت أن إجراءات المستخدم قد لا تزال تؤدي إلى بعض المكالمات.
من وجهة نظر المستخدم ، يجب ألا تحدث الأعطال (مرة أخرى ، رأيي). في الحالات القصوى ، يجب أن يدرك المستخدم أن بعض السيناريوهات قد حدث خطأ وأن فريق التطوير يعمل بالفعل على إصلاحها. تم التعامل مع استثناءات مماثلة دائمًا من قِبلي ، وقد تؤثر على المستخدم في أكثر الأشكال غير الضارة. على سبيل المثال ، واحدة من مئات خلايا الجدول كانت ببساطة غير مرئية.
مع المستخدم أكثر أو أقل كل شيء واضح. يبقى للتعامل مع تسليم سجلات للمطور. أولاً ، كان مطلوبًا بأقل جهد ممكن لاستبدال المكالمات الحالية في الكود بمكالمات ترسل سجلات في مكان ما خارج التطبيق. ثانياً ، كان من الضروري تحديد مكان الحادث بدقة ، وإلا سيكون من المستحيل عملياً ربط الاستثناء بالكود الحقيقي. ثالثًا ، تجدر الإشارة إلى أن المكالمات المعدلة يمكن أن تعمل أثناء اختبار الوحدة ، حيث يجب أن يتم تجاهل
Thread.isMainThread
بالفعل. يمكنني استخدام إطار عمل
RxTest لأنواع معينة من الاختبارات (هنا أنا مستعد أيضًا للاستماع إلى النصائح والنقد). بقيت النقطة الرئيسية هي أن جميع الاستثناءات محليا يجب أن يتم تشغيلها كما كان من قبل ، أي يجب إطلاق النار
Loggin.assert()
في نفس الوقت الذي إطلاق النار
Swift.assert()
يوفر النسيج (
Crashlytics ) طريقة رائعة لإرسال الأحداث. يبدو مثل هذا:
Crashlytics.sharedInstance().recordCustomExceptionName("", reason: ""...
يبقى لتعبئة
Crashlytics في بعض الأطر التي يمكن تحميلها
بالكامل في التطبيق وبصورة مقطوعة (بدون تبعية
Crashlytics ) في أهداف الاختبار.
قررت أن أفعل "
التغليف " من خلال
CocoaPods :
Pod::Spec.new do |s| s.name = 'Logging' ... s.subspec 'Base' do |ss| ss.source_files = 'Source/Logging+Base.swift' ss.dependency 'Crashlytics' end s.subspec 'Test' do |ss| ss.source_files = 'Source/Logging+Test.swift' end end
رمز "الهدف القتالي" هو كما يلي:
import Crashlytics public enum Logging { public static func send(_ reason: String? = nil, __file: String = #file, __line: Int = #line) { let file = __file.components(separatedBy: "/").last ?? __file let line = "\(__line)" let name = [line, file].joined(separator: "_") Crashlytics.sharedInstance().recordCustomExceptionName(name, reason: reason ?? "no reason", frameArray: []) } public static func assert(_ assertion: @escaping @autoclosure () -> Bool, reason: String? = nil, __file: String = #file, __line: Int = #line) { if assertion() == false { self.assertionFailure(reason, __file: __file, __line: __line) } } public static func assert(_ assertion: @escaping () -> Bool, reason: String? = nil, __file: String = #file, __line: Int = #line) { if assertion() == false { self.assertionFailure(reason, __file: __file, __line: __line) } } public static func assertionFailure(_ reason: String? = nil, __file: String = #file, __line: Int = #line) { Swift.assertionFailure(reason ?? "") self.send(reason, __file: __file, __line: __line) } }
ل "هدف الاختبار" أي بدون اعتماد
Crashlytics :
import Foundation public enum Logging { public static func send(_ reason: String? = nil, __file: String = #file, __line: Int = #line) {
النتائج:
بدأت استثناءات حقا للعمل. أبلغ معظمهم عن تنسيق غير صحيح للبيانات المستلمة: تم
Decodable
البيانات في بعض الأحيان مع البيانات ذات النوع
Decodable
. في بعض الأحيان تعمل سجلات
Thread.isMainThread
، والتي تم إصلاحها بسرعة كبيرة في الإصدارات التالية. تم
اكتشاف الأخطاء الأكثر إثارة للاهتمام من قبل
NSException .
شكرا لاهتمامكم
ملاحظة: إذا كنت ترسل هذه السجلات غالبًا إلى
Crashlytics ، فقد تتعرف الخدمة على
تصرفاتك كرسائل غير مرغوب فيها. وسترى الرسالة التالية:
بسبب الاستخدام غير السليم ، تم تعطيل التقارير غير المميتة للبنيات المتعددة. تعرّف على كيفية إعادة تمكين إعداد التقارير في وثائقنا.
لذلك ، يجدر النظر مقدمًا في وتيرة إرسال السجلات. خلاف ذلك ، قد تكون جميع سجلات البناء في خطر التعرض للتجاهل من قبل
Crashlytics.