FlexUnit 구성요소 테스트 패턴:addAsync를 사용하거나 수동으로 초기화하시겠습니까?

Question

우리는 직장에서 약 6개월 동안 Flex를 사용해 왔으며 사용자 정의 구성 요소와 관련된 첫 번째 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에서는 표시 목록에 추가된 후 비동기적으로 이 작업이 수행됩니다.따라서 이러한 상황이 발생했을 때 알림을 받을 수 있도록 콜백(FlexUnit의 addAsync 함수 사용)을 설정해야 합니다.

최근에는 런타임이 필요한 위치에서 호출하는 메서드를 수동으로 호출해 왔기 때문에 이제 내 테스트는 다음과 같이 보이는 경향이 있습니다.

    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...
        }

이것은 따라하기가 훨씬 쉽지만 어느 쪽이든 조금 바람을 피우는 것처럼 느껴집니다.첫 번째 경우는 현재 애플리케이션(단위 테스트 실행기 셸 앱이 됨)에 적용하는 것이고 후자는 "실제" 환경이 아닙니다.

다른 사람들은 이런 상황을 어떻게 처리할지 궁금합니다.

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 위키, 자세한 내용은 여기를 참조하세요.).