iphone - اختبارات iOS/المواصفات TDD/BDD والتكامل واختبار القبول




rspec cucumber (6)

ليرة تركية، والدكتور

في Pivotal ، كتبنا Cedar لأننا نستخدم Rspec ونحبها في مشاريع Ruby الخاصة بنا. لا يهدف Cedar إلى استبدال أو التنافس مع OCUnit؛ من المفترض أن تجلب إمكانية اختبار نمط BDD إلى Objective C ، تمامًا كما كان Rspec رائداً في اختبار نمط BDD في Ruby ، ​​ولكنه لم يقض على Test :: Unit. اختيار واحد أو آخر هو إلى حد كبير مسألة تفضيلات الأنماط.

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

اجابة طويلة

اتخاذ قرار بين اثنين من أطر الاختبار مثل Cedar و OCUnit (على سبيل المثال) يأتي إلى شيئين: الأسلوب المفضل ، وسهولة الاستخدام. سأبدأ بالأسلوب ، لأن هذا ببساطة مسألة رأي وتفضيل. سهولة الاستخدام تميل إلى أن تكون مجموعة من المبادلات.

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

الميزة الأساسية للاختبار على نمط xUnit هي بساطته ، والتبني الواسع (بين المطورين الذين يكتبون اختبارات الوحدة) ؛ تقريبا أي لغة يمكن أن تفكر في كتابة الكود بها إطار عمل على نمط xUnit.

تميل أطر أسلوب BDD إلى وجود فرقتين رئيسيتين عند مقارنتهما بنمط xUnit: كيف تقوم ببناء الاختبار (أو المواصفات) ، وبناء الجملة لكتابة تأكيداتك. بالنسبة لي ، الفرق البنيوي هو الاختلاف الرئيسي. اختبارات xUnit هي ذات بعد واحد ، مع طريقة setUp واحدة لجميع الاختبارات في فئة اختبار معينة. إلا أن الفصول التي نختبرها ليست ذات بعد واحد. نحتاج في كثير من الأحيان إلى اختبار الإجراءات في العديد من السياقات المختلفة ، والتي قد تكون متضاربة. على سبيل المثال ، ضع في اعتبارك فئة ShoppingCart بسيطة ، باستخدام طريقة addItem: (لأغراض هذه الإجابة ، سأستخدم صيغة Objective C). قد يختلف سلوك هذه الطريقة عندما تكون سلة التسوق فارغة مقارنة بعُربة احتواء العربة على عناصر أخرى ؛ قد تختلف إذا أدخل المستخدم رمز الخصم. قد تختلف إذا لم يمكن شحن العنصر المحدد بواسطة طريقة الشحن المحددة ؛ وما أن تتقاطع هذه الشروط مع بعضها البعض ، ينتهي بك الأمر بعدد متزايد هندسيًا من السياقات المحتملة ؛ في اختبار xUnit- نمط هذا غالباً ما يؤدي إلى الكثير من الأساليب مع أسماء مثل testAddItemWhenCartIsEmptyAndNoDiscountCodeAndShippingMethodApplies. يسمح لك هيكل أطقم تصميم BDD بتنظيم هذه الشروط بشكل فردي ، والتي أجدها تجعل من السهل التأكد من تغطية جميع الحالات ، بالإضافة إلى سهولة العثور عليها أو تغييرها أو إضافة شروط فردية. على سبيل المثال ، باستخدام بناء جملة Cedar ، تبدو الطريقة المذكورة أعلاه كالتالي:

describe(@"ShoppingCart", ^{
    describe(@"addItem:", ^{
        describe(@"when the cart is empty", ^{
            describe(@"with no discount code", ^{
                describe(@"when the shipping method applies to the item", ^{
                    it(@"should add the item to the cart", ^{
                        ...
                    });

                    it(@"should add the full price of the item to the overall price", ^{
                        ...
                    });
                });

                describe(@"when the shipping method does not apply to the item", ^{
                    ...
                });
            });

            describe(@"with a discount code", ^{
                ...
            });
        });

        describe(@"when the cart contains other items, ^{
            ...
        });
    });
});

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

والفرق الرئيسي الثاني بين أطر نمط BDD وأطر xUnit-style ، أو بنية التوكيد (أو "المطابق") ، ببساطة يجعل نمط المواصفات أجمل نوعًا ما ؛ بعض الناس يحبون ذلك حقا ، والبعض الآخر لا.

وهذا يؤدي إلى مسألة سهولة الاستخدام. في هذه الحالة ، يكون لكل إطار مزاياه وسلبياته:

  • تم OCUnit حول أطول بكثير من سيدار ، ويتم دمجها مباشرة في Xcode. وهذا يعني أنه من السهل إجراء اختبار هدف جديد ، وفي معظم الأحيان ، إجراء الاختبارات وتشغيلها "مجرد أعمال". من ناحية أخرى ، وجدنا أنه في بعض الحالات ، مثل التشغيل على جهاز iOS ، كان من الصعب الحصول على اختبارات OCUnit. إن إعداد مواصفات Cedar يأخذ بعض العمل أكثر من اختبارات OCUnit ، لأنك تحصل على المكتبة وتربطها بنفسك (لا تكون أبداً مهمة تافهة في Xcode). نحن نعمل على تسهيل الإعداد ، وأي اقتراحات أكثر من موضع ترحيب.

  • يقوم OCUnit بتشغيل الاختبارات كجزء من البناء. هذا يعني أنك لست بحاجة إلى تشغيل برنامج قابل للتنفيذ لإجراء الاختبارات الخاصة بك ؛ إذا فشلت أي اختبارات ، فشل بناء الخاص بك. هذا يجعل عملية تشغيل الاختبارات خطوة واحدة أبسط ، وينتج إختبار الإنتاج مباشرة في نافذة إخراج البناء مما يجعل من السهل رؤيتها. لقد اخترنا بناء مواصفات Cedar على برنامج قابل للتنفيذ والذي يتم تشغيله بشكل منفصل لعدة أسباب:

    • أردنا أن نكون قادرين على استخدام المصحح. يمكنك تشغيل مواصفات Cedar مثلما تقوم بتشغيل أي برنامج قابل للتنفيذ ، بحيث يمكنك استخدام المصحح بنفس الطريقة.
    • أردنا تسجيل وحدة التحكم سهلة في الاختبارات. يمكنك استخدام NSLog () في اختبارات OCUnit ، ولكن الإخراج يدخل في إطار الإنشاء حيث يجب عليك إنشاء خطوة البناء لقراءته.
    • أردنا سهولة قراءة تقارير الاختبار ، سواء على سطر الأوامر أو في Xcode. تظهر نتائج OCUnit بشكل جيد في نافذة البناء في Xcode ، ولكن بناء من سطر الأوامر (أو كجزء من عملية CI) ينتج عنه مخرجات اختبار متداخلة مع الكثير والكثير من مخرجات البناء الأخرى. مع مراحل البناء والتشغيل المنفصلة ، يقوم Cedar بفصل الإخراج بحيث يكون من السهل العثور على خرج الاختبار. يقوم عداد اختبار Cedar الافتراضي بنسخ النمط القياسي للطباعة "." لكل المواصفات المارة ، "F" للمواصفات الفاشلة ، إلخ. Cedar لديه القدرة على استخدام كائنات المراسلات المخصصة ، بحيث يمكنك الحصول على نتائج الإخراج بالطريقة التي تريدها ، مع القليل من الجهد.
  • OCUnit هو إطار اختبار الوحدة الرسمي للهدف C ، وهو معتمد من Apple. لدى Apple موارد غير محدودة أساسًا ، لذلك إذا أرادوا تنفيذ شيء ما ، فسيتم إنجازه. وعلى كل حال ، هذا هو صندوق رمل أبل الذي نلعب فيه. لكن الجانب الآخر من هذه العملة ، هو أن شركة آبل تستلم طلبات طلبات الدعم من Bajillion وتقارير الأخطاء كل يوم. فهي جيدة بشكل ملحوظ في التعامل معها جميعًا ، ولكنها قد لا تكون قادرة على التعامل مع المشكلات التي تبلغ عنها على الفور ، أو على الإطلاق. Cedar هو أحدث وأقل مخبوزات من OCUnit ، ولكن إذا كان لديك أسئلة أو مشاكل أو اقتراحات ، أرسل رسالة إلى قائمة Cedar البريدية ([email protected]) وسنفعل ما في وسعنا لمساعدتك. أيضًا ، لا تتردد في إنشاء الشفرة من Github (github.com/pivotal/cedar) وإضافة أي شيء تعتقد أنه مفقود. نحن نجعل أطر اختبارنا مفتوحة المصدر لسبب ما.

  • قد يكون من الصعب إجراء اختبارات OCUnit على أجهزة iOS. بصراحة ، لم أجرب هذا منذ بعض الوقت ، لذلك قد يكون الأمر أسهل ، ولكن في المرة الأخيرة التي حاولت فيها ، لم أتمكن ببساطة من الحصول على اختبارات OCUnit لأي وظيفة UIKit للعمل. عندما كتبنا سيدار ، تأكدنا من أننا نستطيع اختبار الكود المعتمد على UIKit على كل من المحاكاة وعلى الأجهزة.

وأخيرًا ، كتبنا Cedar لاختبار الوحدة ، مما يعني أنه غير قابل للمقارنة مع مشروعات مثل UISpec. لقد مر وقت طويل منذ أن حاولت استخدام UISpec ، لكنني فهمت أنه يركز بشكل أساسي على قيادة واجهة المستخدم برمجيًا على جهاز iOS. قررنا على وجه التحديد عدم محاولة دعم Cedar لهذه الأنواع من المواصفات ، لأن Apple كانت (في ذلك الوقت) على وشك الإعلان عن استخدام تقنية UIAutomation.

ما هي أفضل التقنيات المستخدمة في تطوير السلوك على iPhone؟ وما هي بعض الأمثلة على مشاريع المصادر المفتوحة التي توضح الاستخدام السليم لهذه التقنيات؟ فيما يلي بعض الخيارات التي وجدتها:

وحدة التجارب

Test::Unit نمط Test::Unit

  1. OCUnit/SenTestingKit كما هو موضح في دليل تطوير iOS: تطبيقات اختبار الوحدة ومراجع OCUnit الأخرى.
  2. CATCH
  3. GHUnit
  4. Google Toolbox for Mac: اختبار وحدة iPhone

نمط RSpec

  1. Kiwi (الذي يأتي أيضا مع السخرية والتوقعات)
  2. Cedar
  3. Jasmine مع UI Automation كما هو موضح في مواصفات "iOS-Acceptance-Testing"

اختبار القبول

نمط Selenium

  1. UI Automation (يعمل على الجهاز)

    استكمال: يبدو Zucchini إطار لخلط أتمتة Cucumber & UI! :)

    مشاركات المدونة القديمة:

  2. UISpec مع UISpecRunner

  3. FoneMonkey

نمط Cucumber

  1. Frank و iCuke (على أساس الخيار يجتمع فون الحديث )

  2. KIF (حافظ على وظيفتها) بواسطة Square

  3. يستخدم Zucchini Framework بناء جملة Cucumber لكتابة الاختبارات ويستخدم CoffeeScript للتعريفات الخطوة.

الإضافات

استنتاج

حسنًا ، من الواضح أنه لا توجد إجابة صحيحة لهذا السؤال ، ولكن إليك ما أختاره حاليًا:

لاختبار وحدة ، اعتدت على استخدام OCUnit/SenTestingKit في OCUnit/SenTestingKit 4. انها بسيطة وصلبة. ولكن ، أنا أفضل لغة BDD عبر TDD ( لماذا يعتبر RSpec أفضل من Test :: Unit ؟) لأن كلماتنا تخلق عالمنا. حتى الآن ، أنا استخدم الكيوي مع ARC & كيوي إكمال قانون / autocompletion . أنا أفضل الكيوي على سيدار لأنه مبني على رأس OCUnit ويأتي مع قاذفات RSPec على غرار وموكز / بذرة. استكمال: أنا الآن أبحث في OCMock لأنه ، حاليا ، لا يدعم الكيوي stubbing الأجسام المرورية المجانية .

لاختبار القبول ، أستخدم أتمتة UI لأنه رائع. يتيح لك تسجيل كل حالة اختبار ، مما يجعل اختبارات الكتابة تلقائية. أيضا ، أبل تطويره ، لذلك لديه مستقبل واعد. يعمل أيضًا على الجهاز ومن الأدوات التي تسمح بميزات رائعة أخرى ، مثل إظهار تسرب الذاكرة. لسوء الحظ ، مع UI Automation ، لا أعرف كيفية تشغيل كود Objective-C ، ولكن مع Frank و iCuke يمكنك ذلك. لذلك ، سأقوم فقط باختبار الأشياء ذات المستوى الأقل من المستوى C مع اختبارات الوحدة ، أو إنشاء UIButton s فقط لتكوين UIButton TEST ، والتي عند النقر عليها ، سيتم تشغيل كود Objective-C.

ما هي الحلول التي تستخدمها؟

أسئلة ذات صلة


GHUnit جيد لاختبارات الوحدة ؛ لاختبارات التكامل ، لقد استخدمت UISpec مع بعض النجاح (github fork هنا: https://github.com/drync/UISpec ) ، ولكن أتطلع إلى تجربة iCuke ، حيث أنه يعد بأن يكون إعدادًا خفيف الوزن ، ويمكنك استخدام القضبان اختبار الخير ، مثل RSpec والخيار.


أنا حقا أحب OCDSpec2 لكنني منحازة ، كتبت OCDSpec والمساهمة في الثانية.

إنه سريع جدًا حتى على نظام التشغيل iOS ، ويرجع ذلك جزئيًا إلى أنه تم إنشاؤه من الألف إلى الياء بدلاً من وضعه على قمة OCUnit. لديها بناء RSPec / الياسمين كذلك.

https://github.com/ericmeyer/ocdspec2


بالنسبة إلى التطوير القائم على الاختبار ، أحب استخدام GHUnit ، GHUnit ، ويعمل بشكل رائع لتصحيح الأخطاء أيضًا.


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


قائمة كبيرة!

لقد وجدت حلًا آخر مثيرًا للاهتمام لتطبيقات UI لاختبار iOS.

كوسة الاطار

ويستند على UIAutomation . يتيح لك الإطار كتابة سيناريوهات سيناريو مركزية في نمط مثل نمط. يمكن تنفيذ السيناريوهات في Simulator وعلى الجهاز من وحدة تحكم (وهو CI مألوف).

التأكيدات هي قطة مقرها. يبدو غير مرن ، ولكنه يحصل على تقرير HTML جيد ، مع مقارنة شاشة مميزة ويمكنك توفير أقنعة تحدد المناطق التي ترغب في الحصول على تأكيد دقيق لها.

كل شاشة لابد من وصفها في CoffeScript والأداة نفسها مكتوبة في روبي. إنه نوع من الكابوس UIAutomation ، لكن الأداة توفر تجريدًا لطيفًا من أجل UIAutomation وعندما يتم وصف الشاشات يمكن التحكم فيها حتى بالنسبة لشخص QA.





ios-ui-automation