이름만으로도 반쯤 알 수 있는 프레임웍 — ActionScript (2.0, 3.0 모두 지원) 기반의 xUnit 류의 유닛테스트 프레임웍이다.
몇 일간 써본걸 토대로 간략히 장단점을 논하자면.
장점
xUnit 류의 인터페이스라는 것. 덕분에 xUnit 계통을 다른 언어에서 써본 사람이라면 일단 한 번만 전체 구성이 나오면, 별 어려움없이 바로 사용할 수 있다. setUp(), test테스트이름(), tearDown() 으로 이어지는 테스트 준비, 개별 테스트, 테스트 뒷처리의 형태는 일단 익숙하고 / 바로 사용할 수 있어서 상당한 장점이라고 생각한다.1
ActionScript 에서 간략한 수준의 reflection을 사용할 수 있기 때문에, 그걸 이용해서 test???() 인 함수들은 전부 실행되서 C++ 에서처럼 복잡하게 (내부적으로) 테스트들을 등록시키는 수고가 필요하지 않다. Adobe의 Flash 제작툴이나 Flex Builder와도 연동이 가능하며, 현재 사용 중인 ActionScript 컴파일러인 mtasc 에서도 무난히 동작한다. 그리고 나름대로(?) xUnit의 상징인 녹색바도 볼 수 있다.
단점
ActionScript 자체의 단점과 맞닿아있는 부분인데, 파일 수가 너무 많다 — 그것도 사용자가 간섭해서 만들어줘야하는 것들이.
ActionScript의 대전제(?)인 클래스당 파일 하나라는 것 덕분에 최소한 이런 수의 파일들이 생긴다.
- TestRunner.as — 테스트를 실행해주는 스크립트. 이 녀석이 main() 역할을 한다
- AllTest.as — 모든 테스트 케이스가 든 파일들을 열거하기 위한 녀석. 일종의 suite 느낌?
- Test???.as — 특정 클래스를 테스트하기 위한 파일
- 실제 클래스 — 작성할 클래스 파일.
이런 식으로 실제 클래스 / Test 클래스 쌍이 심각하게 증가하게 되고, 이걸 AllTest.as 에 반영해야하는 것도 정적으로 적어줘야하는 것도 좀 스트레스. 그리고 ActionScript 최대의 문제인 (Flex 3은 모르겠고) 커맨드라인 자동화가 불가능한 것 — 결국엔 웹 브라우져 refresh 로 실행해야한다는 것.2
커맨드라인 인자를 받거나 할 수 없기 때문에 특정 suite이나 test-case 만 실행한다거나하는 일은 꿈에도 못 꾸고, 자동화된 테스트 리포트도 넣을 수 없다. 그래도 이런 거라도 있는게 어디야.