أنماط اختبار مكونات FlexUnit:استخدام addAsync أو التهيئة يدويًا؟

Question

نحن نستخدم Flex منذ حوالي 6 أشهر هنا في العمل، ووجدت أن الدفعات الأولى من اختبارات FlexUnit التي تتضمن مكونات مخصصة ستميل إلى اتباع هذا النوع من النمط:

import mx.core.Application;
import mx.events.FlexEvent;
import flexunit.framework.TestCase;

public class CustomComponentTest extends TestCase {
    private var component:CustomComponent;

    public function testSomeAspect() : void {
        component = new CustomComponent();
        // set some properties...

        component.addEventListener(FlexEvent.CREATION_COMPLETE, 
            addAsync(verifySomeAspect, 5000));

        component.height = 0;
        component.width = 0;
        Application.application.addChild(component);
    }

    public function verifySomeAspect(event:FlexEvent) : void {
        // Assert some things about component...
    }

    override public function tearDown() : void {
        try {
            if (component) {
                Application.application.removeChild(component);
                component = null;
            }
        } catch (e:Error) {
            // ok to ignore
        }
    }

في الأساس، تحتاج إلى التأكد من تهيئة المكون بالكامل قبل أن تتمكن من التحقق بشكل موثوق من أي شيء يتعلق به، وفي Flex يحدث هذا بشكل غير متزامن بعد إضافته إلى قائمة العرض.لذلك تحتاج إلى إعداد رد اتصال (باستخدام وظيفة addAsync الخاصة بـ FlexUnit) ليتم إعلامك عند حدوث ذلك.

لقد قمت مؤخرًا باستدعاء الطرق التي سيستدعيها وقت التشغيل يدويًا في الأماكن الضرورية، لذا تميل اختباراتي الآن إلى أن تبدو أكثر مثل هذا:

    import flexunit.framework.TestCase;

    public class CustomComponentTest extends TestCase {

        public function testSomeAspect() : void {
            var component:CustomComponent = new CustomComponent();
            component.initialize();
            // set some properties...
            component.validateProperties();

            // Assert some things about component...
        }

هذا أسهل بكثير في المتابعة، لكن يبدو الأمر وكأنني أغش قليلاً في كلتا الحالتين.الحالة الأولى هي إدخاله في التطبيق الحالي (والذي سيكون بمثابة تطبيق Shell لمشغل اختبار الوحدة)، والأخير ليس بيئة "حقيقية".

كنت أتساءل كيف سيتعامل الآخرون مع هذا النوع من المواقف؟

Answer 1

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

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

هل يمكن أن نلقي نظرة على dpUint'س تسلسلات, لقد جعلوا اختبار المكونات أكثر وضوحًا:

public function testLogin():void {
    var passThroughData:Object = new Object();

    passThroughData.username = "myuser1";
    passThroughData.password = "somepsswd";

    var sequence:SequenceRunner = new SequenceRunner(this);

    sequence.addStep(new SequenceSetter(form.usernameTI, {text:passThroughData.username}));
    sequence.addStep(new SequenceWaiter(form.usernameTI, FlexEvent.VALUE_COMMIT, 100));

    sequence.addStep(new SequenceSetter(form.passwordTI, {text:passThroughData.password}));
    sequence.addStep(new SequenceWaiter(form.passwordTI, FlexEvent.VALUE_COMMIT, 100));

    sequence.addStep(new SequenceEventDispatcher(form.loginBtn, new MouseEvent("click", true, false)));
    sequence.addStep(new SequenceWaiter(form, "loginRequested", 100));

    sequence.addAssertHandler(handleLoginEvent, passThroughData);

    sequence.run();
}

(مثال من dpUint ويكي, انظر هنا لمزيد من المعلومات).