최근 시간 날 때마다 짬짬히 Mustella를 이용한 테스트 프레임워크를 구현하고 있는데, 쓸만한 성과가 있어서, 쌓여있는 글1들을 뒤로 하고 먼저 포스팅한다.
Flex의 Mustella는 상당히 구조가 묘하게(?)되어있는데, 문법 내 Flex의 Binding을 전혀 이용하지 않고, MXML만으로 테스트를 구성한다.
그런데, 이 구조를 잘 살펴보다보니, MXML은 Declarative(선언적) 프로그래밍 언어라, 이를 잘 이용하면, 매우 용이하게 Test 생성기, 해석기를 만들 수 있음을 깨달았다.
선언적 언어 (Declarative Langauge)
MXML은 XML이다보니, 문법적인 해석에 어려움 없이, 있는 그대로 읽어들이면 된다. 하나의 Node가 정확히 하나의 자연어 문장의 구조를 가지고 있고, 또 사용자의 입력 등, 개발자 관점이 아닌 사용자 관점에서 동작을 서술하고 있기 때문에, 자연어로의 변환이 매우 용이하다.
더보기
Simple Structure
물론, 대부분의 XML기반의 DSL(Domain-Specific Language)들은 이와 비슷한 특성을 가지고 있다.
하지만 한편으로, 대부분의 DSL은, 많은 기능을 지원하려다보니, 내부적으로 다소 복잡한 구조를 가지고 있어, GUI 기반의 에디터로 구현을 한다고 하여도, 쉽사리 단순화되지 않는 문제가 있다.
반면에, Mustella의 경우는, 그 구조가 매우 단순하면서도, GUI 테스트에 필요한 거의 모든 기능을 표현하고 있다.2 특히 Software Test에 주로 사용되는 User Story의 경우, 이러한 간결한 구조의 DSL로 표현하기에 매우 효율적이다.
기존 테스트의 단점
현재 사용되고있는 여러가지 테스트들의 가장 큰 문제는, 테스트 작성에 생각보다 많은 시간이 소요된다는 점이다.
현재 작성중인 글 중 '소프트웨어 테스트의 미래'라는 글에서 언급한 내용 중, 해외 개발자인 James Whittaker는 그의 인터뷰에서, 미래에는 소프트웨어 테스트 스위트들이 독립적 가치로 인정받아, 테스트 스위트에 대한 거래가 일어나게 될 것이라고 이야기했다. 그의 이러한 예측이 나오게 된 전제는, 테스트 작성에 많은 시간과 노력이, 즉 큰 비용이 투자되고 있다는 것일 것이다. 그리고 그 비용을 줄이기 위해, 이미 작성된 재사용 가능한 테스트를 구매하려는 기업들이 생겨날 것이라는 것이 그의 논리라는 생각이다.
물론, Software Test용 DSL을 도입한다고 해서, 이미 만들어진 테스트를 재사용하는 것보다 비용이 적게 들 것이라고 생각지는 않는다. 다만, Mustella의 경우, 일반적인 XML 파서로 매우 간단하게 테스트를 생성하거나 해석할 수 있고, 더 나아가, 이를 테스트 생성기로 제작함으로서, 웹 페이지 등에서, 서너번의 버튼 클릭만으로도 원하는 테스트를 쉽게 생성해낼 수 있을 것으로 보인다.
자연어 요구 사항과 자연어 테스트
소프트웨어의 요구 사항은, 고객으로부터, 또는 사용자로부터 발생하며, 자연어로 되어있다. 그리고, 기획자들은 이 자연어 요구 사항을, 보다 상세한 자연어 스펙으로 작성하여 QA 엔지니어들에게 넘긴다. QA 엔지니어들은 이러한 자연어 스펙을 다시 프로그래밍 언어로 변환하여 테스트를 작성한다.
만약 테스트도 자연어로 개발이 가능하다면 어떨까?
Mustella의 가장 큰 특징은, 자연어로의 자연스러운 변환이 가능하다는 것이다. 또한 그 구조가 매우 간결하여, 자연어로 변환하였을 때, 프로그래밍에 익숙하지 않은 사람들이 이해하기에 쉽고, 또 그 역변환도 매우 용이하다는 것이다.
아래는 현재 테스트중인 테스트 생성기의 스크린샷.
오늘 오전에 급히 만들어본 것이라 이게 뭔가 싶겠지만, 이 테스트 케이스를 실행하기 위해 어떤 동작들이 이루어지는지 쉽게 알 수 있다. 또한 추후에는 위의 Setup/Body/Cleanup 밑의 각 Action 버튼들을 자연어로 변환할 예정.
결론
요즘의 소프트웨어 개발에서, 소프트웨어 테스트는 소프트웨어의 요구 사항 문서와도 동일시되고 있어, 생산성과 접근성이 매우 중요한데, Mustella를 이용한 테스트 생성기를 개발하면, 프로그래밍 언어에 익숙치 않은 기획자/디자이너들이 쉽게 사용할 수 있는, 더욱 자연어에 가까운 테스트 생성 툴을 제공할 수 있을 것으로 보인다.
개인적으로는, 2006년경에 시도했던 DDD(Documentation Driven Development: 문서화 주도 개발)을 다시 도전해볼 수 있는 계기가 될 듯..
아래는 Flex SDK 4의 여러 컴포넌트를 테스트하는 check-in 테스트 및 스모크 컴포넌트 테스트의 실행 동영상.
음.. 일단 하던 일부터 마저 마무리를 해야지..
마치며 덧붙임
현재 Mustella의 가장 큰 문제점은 아무래도 컴파일 속도. 소프트웨어 테스트에서 가장 중요한 것 중 한 가지는, 각각의 테스트 결과를 빠르게 받아볼 수 있어야한다는 점이며, 그 간격이 빠를수록 더 빠른 개발이 가능하다. 그런데 Mustella의 경우, 어플리케이션을 테스트하는 특성 상 mxmlc로 컴파일하는 과정을 거치게 되는데, 그 속도가 다소 불만족스럽다. 현재 최고 사양의 MacBook Pro(3.0Ghz/8GB/256SSD)를 사용중인데, (작은 규모의 어플리케이션임에도 불구하고) 각 어플리케이션당 컴파일속도가 15초 가량 걸린다.3 상황에 따라서는 각 유즈 케이스마다 한 번씩 컴파일을 해야할 수 있어, 이 시간을 어떻게 단축시킬 것인지가 가장 관건이 될 것으로 보인다.
마친 후 덧붙임
속도 문제는, incremental 옵션을 주고, 개발 시에는 선택적으로 테스트를 컴파일/실행하고, check-in 시에만 전체 테스트를 실행하도록 하면 될 듯. 구현할 시간이 있다는 가정 하에.
제안 및 참여
2010년 상반기 진행 예정인 Flex 또는 AIR 프로젝트에서, 위 내용으로 Continuous Integration / Test Automation 도입을 원하는 업체는 본 블로그의 방명록, 또는 Linknow를 통해 연락을 바랍니다.
'Adobe Flash Platform > Flex' 카테고리의 다른 글
| [뉴스] Flex 4 SDK - AIR 1.5.3 / FP 10.0.42 적용 (0) | 2009/12/11 |
|---|---|
| setActualSize()와 move() (9) | 2009/12/08 |
| Mustella와 Test 생성기 (8) | 2009/12/08 |
| Array.indexOf()가 괴롭힐 때 (0) | 2009/11/28 |
| 성능을 논하기 전에 (0) | 2009/11/28 |
| Function.apply()를 이용한 퍼포먼스 튜닝 (3) | 2009/11/27 |
댓글을 달아 주세요
와우~ 동영상 보니까 쥑이는데요.
TDD 개발을 단순히 알고리즘 개발 분야쪽으로 치우쳐서 생각하고 있었는데 인터렉션쪽 자동화 테스트도 이런식으로 하면 되겠구나 하고 감이 확 오네요..^^ 실제로 자동화 테스트하는걸 본적이 없어서리..ㅎㅎ 조은거 보고 갑니다.
저도 처음 접했을 때는 정말 깜놀. ㅎㅎ
요건 TDD와는 약간 다른, BDD(Behavior Driven Development)라는 분야입니다.
TDD가 Bottom-up 방식이라면, BDD는 Top-Down 방식이라고 보시면 될 것 같아요.
사용자 스토리를 먼저 정의하고, 그 스토리에 해당하는 테스트를 작성하는 방식이라, TDD에 비해서 조금 느슨하지만, 반면에 그만큼 실용적이라고 할 수 있을 것 같아요. :')
BDD 는 또 처음듣는 거네요 ㅋㅋ 뭔가가 하도 많아서리..
덕분에 검색질좀 해봐야겠네요 --;
ㅎㅎ TDD의 저자인 David Astels가 소개하면서 널리 알려진, 그리고 현재도 연구가 진행중인 테스트 방법이에요.
저보다 2~3년씩 앞서있는 해외 개발자들을 보면 참.. ㅎㅎ
재영 2009/12/11 10:11 댓글주소 수정/삭제 댓글쓰기
찬익아.. 우리 업체에서 관심있는데 공짜로 해줘 -_-
그래도 최소한 밥값은 나와야 ㅎㅎ
이거 물건이군요.
2010년 중으로 패턴화시켜서 솔루션으로 발전할 수 있으면 좋겠어요. :')