더 나은 자바스크립트 테스팅을 위한 가이드
OSS
게시글 작성 시각 2014-03-18 20:39:31
2014년 03월 17일 (월)
ⓒ ITWorld, Jonathan Freeman | InfoWorld
간단히 말하면 자바스크립트에서 코드 테스트는 필수다. 하지만 이 과정을 지원해 줄 간편한 툴을 알지 못하면 정말 고통스러운 작업이 바로 테스팅이다. 필자 역시 초보 개발자 시절 테스팅이 가장 고민이었다. '테스트 러너'(test runer)가 그 고통의 핵심이었다. 테스트 러너는 테스트 프레임워크와 필자의 자바스크립트 파일 전부, 테스트 파일 전부를 포함한 HTML 페이지로 이뤄져 있다. 여기서 테스트를 실행하려면 브라우저 내 페이지를 열고 이를 실행시켜 결과를 확인해야 했다.
테스트가 실패하면 코드를 고쳐 브라우저로 다시 돌려보내고 새로고침을 하거나, 여러 브라우저에서 테스트하고 이를 모두 새로 고치고 각각의 결과물을 관찰해야 했다. 게다가 소스 파일이나 테스트를 추가하려면 일일이 수작업으로 테스트 러너 페이지를 수정해 새 파일을 포함시켜야 했다. 이러한 일련의 과정은 일을 기하급수적으로 늘렸고, 테스트가 얼마나 힘든 일인가를 여실히 보여줬다.
그렇다면 이런 작업을 더 쉽게 만들어줄 훌륭한 툴이 있지 않을까? 당연히 있다. 오히려 문제는 너무 많은 것이다. 여기 필자가 가장 좋아하는 툴을 소개하고 사용법을 공유한다.
카르마 시작하기
카르마(Karma)는 이제 필자가 테스팅 과정에서 가장 자주 사용하는 툴이다. 이전까지 테스타큘라(Testacular)라고 불렸던 카르마는 매우 훌륭한 자동 테스트 러너다. 구글의 앵귤러.js(Angular.js) 팀이 관리하는 카르마는 기능성이 좋고 확장도 쉽다.
예를 들어 실제 테스트를 하려면 자바스크립트 프로젝트 루트 디렉터리에서부터 카르마를 실행하라. 그거면 된다. 그러면 자동으로 구성 파일에 정해둔 모든 브라우저를 실행한다. 그 후 카르마는 파일 시스템 변경을 검사해 이 내용을 저장한 후 모든 브라우저에서의 테스트 결과를 보여준다.
단점이라면 사용자가 원하는 테스트로 구성 파일을 미리 준비해두어야 한다는 점이다. 그 파일 자체는 매우 직관적이다. 카르마를 실행하면 기본 사항을 거쳐가며 필요에 따라 파일을 생성한다. 우선은 어떤 프레임워크를 사용 할 지부터 결정해야 한다.
![](http://files.itworld.co.kr/image/2014/03/karma.jpg)
카르마 자체는 테스트 프레임을 가리지 않고, 프레임워크를 처리하는 방법은 플러그인에 의존한다. 플러그인은 재스민(jasmine), 모카(Mocha), 큐유닛(QUnit) 등 대부분의 프레임워크용으로 지원한다. 만약 이들 중 하나를 사용하지 않는다면, 우선 Npm(노드.js를 위한 공식 패키지 관리자)에서 카르마 플러그인을 먼저 확인하라. 테스트 프레임워크용 플러그인이 없다면, 필요한 플러그인을 작성하거나 더 보편적인 프레임워크로 갈아타면 된다.
그 다음은 브라우저 구성 작업을 해야 한다. 카르마는 크롬, 파이어폭스, 인터넷 익스플로러, 오페라 등 설정한 모든 브라우저를 자동으로 실행한다. 추가로 팬텀JS(PhantomJS)나 슬리머JS(SlimerJS)로 헤드리스(headless) 환경에서 테스트할 수도 있다. 이걸로도 충분치 않다면 브라우저스택(BrowserStack)이나 소스(Sauce)로 묶어 가능한 모든 브라우저에서 테스트할 수도 있다.
가령 삼성 TV 브라우저를 테스트하고 싶다면, 기기에 브라우저가 설치돼 있고 네트워크에 접속돼 있는 한 직접 연결해 바로 테스트를 할 수도 있다. 단지 특정 포트에서 호스트 컴퓨터의 IP 주소로 찾아 들어가면 기타 테스트 재가동 등을 포함한 나머지 작업은 자동으로 진행된다.
브라우저를 선택한 후, 카르마가 어디서 파일을 찾을지 지정하라. 만약 순서가 중요하면, 하나씩 파일을 정렬할 수도 있지만 프로젝트를 이런 식으로 설정하는 것은 추천하고 싶지 않다. 대신 리콰이어JS(RequireJS)같은 툴을 활용해 개별 사용자 환경에 맞게 관리하라. 이런 식으로 src/**/*.js 와 test/**/*Spec.js 같은 것들만 포함시키면 그걸로 끝이다. 이제 원하는 대로 파일을 추가 삭제하고 구성 파일은 손대지 마라. 만약 **/*.js 보다 더 작은 해머가 필요하다면, 카르마가 자바스크립트 정규 표현을 이해하기 때문에 이를 한번 털어내고 계속 진행하면 된다.
기본적인 프로젝트로는 이 정도로 충분하다. 이제 카르마가 파일 시스템 변경을 관찰하고, 카르마를 시작 실행하고 테스트 작성을 시작하면 된다.
작업을 위한 더 많은 툴
백본 애플리케이션(특히 템플릿에 관해서)을 테스팅 할 때 사용하는 구성 사양은 다양하고 거기에 또 도움이 될만한 추가 플러그인과 툴도 많다. 그 중 몇 가지를 소개한다.
필자는 재스민을 테스트 프레임워크로 사용한다. BDD 스타일은 내 눈에 잘 들어오고 높은 단계에서 테스트 상황을 추적하는데 도움을 준다. 재스민은 DOM-프리 이기 때문에, HTML에 관해 테스트할 때 재스민-제이쿼리(jasmine-jquery)를 활용하고 싶을 것이다. 이는 재스민이 다양한 종류의 DOM-특정 어서션(assertion)을 포함하고 HTML과 JSON 픽스쳐 로딩 지원을 추가시킨다.
어서션에 관해 이야기할 때, 만약 Node.js 코드를 작성하거나 오직 현대적 브라우저만을 대상으로 할 경우에는 should.js를 진지하게 살펴봐야 한다. 이를 이용하면 어서션 라이브러리로 재스민과 조화롭게 작동하고 깔끔하게 읽힌다. 유일한 문제는 ECMA스크립트 접근자 속성(게터와 세터)을 사용해 인터넷 익스플로러 8과 그 이전 버전 등의 몇몇 브라우저에서 지원하지 않는다는 점이다.
재스민이 목스(mocks)와 스파이스(spies)처럼 많은 테스팅 능력을 제공하지만, XHR 요청을 속이는 능력 지원은 최근에야 시작됐다. 이 새로운 지원은 아직 성숙이 필요하므로 지금까지 써오던 sinon.js를 고수하면서 서버를 대신하게 하겠다. Sinon.js는 수많은 재스민의 기능성과 겹치지만 서버를 한동안 속일 수 있는 능력을 보유해왔고 설정과 사용도 간편하다.
필자가 한 모든 테스팅은 코드가 커버됐는지를 확인하는 것이 목적이다. 필자는 카르마 플러그인을 이스탄불(istanbul) 코드 커버리지 툴로 활용한다. Esprima와 escodegen을 기반으로 구축된 이스탄불은 카르마와 아주 잘 작동한다. 그 자체만으로 이스탄불은 HTML과 LCOV로 보고서를 만들어내지만 카르마 플러그인은 텍스트 아웃풋과 Cobertura XML 지원을 더해주기 때문에 젠킨스(Jenkins)가 이해할 수 있다. 그렇다. 카르마는 지속 통합 툴을 위한 플러그인 역시 지원한다.
![](http://files.itworld.co.kr/image/2014/03/istanbul.jpg)
모두 합쳐져 이 툴들은 필자의 시간 소모와 두통을 상당히 줄여주었다. 만약 자바스크립트 유닛 테스팅이나 현재 테스팅 작업흐름 업그레이드에 관심이 있다면, 하루 이틀 정도 이런 툴들을 시험삼아 써본 후 개별 환경에 맞는 것을 찾아 사용해 보자.
테스트가 실패하면 코드를 고쳐 브라우저로 다시 돌려보내고 새로고침을 하거나, 여러 브라우저에서 테스트하고 이를 모두 새로 고치고 각각의 결과물을 관찰해야 했다. 게다가 소스 파일이나 테스트를 추가하려면 일일이 수작업으로 테스트 러너 페이지를 수정해 새 파일을 포함시켜야 했다. 이러한 일련의 과정은 일을 기하급수적으로 늘렸고, 테스트가 얼마나 힘든 일인가를 여실히 보여줬다.
그렇다면 이런 작업을 더 쉽게 만들어줄 훌륭한 툴이 있지 않을까? 당연히 있다. 오히려 문제는 너무 많은 것이다. 여기 필자가 가장 좋아하는 툴을 소개하고 사용법을 공유한다.
카르마 시작하기
카르마(Karma)는 이제 필자가 테스팅 과정에서 가장 자주 사용하는 툴이다. 이전까지 테스타큘라(Testacular)라고 불렸던 카르마는 매우 훌륭한 자동 테스트 러너다. 구글의 앵귤러.js(Angular.js) 팀이 관리하는 카르마는 기능성이 좋고 확장도 쉽다.
예를 들어 실제 테스트를 하려면 자바스크립트 프로젝트 루트 디렉터리에서부터 카르마를 실행하라. 그거면 된다. 그러면 자동으로 구성 파일에 정해둔 모든 브라우저를 실행한다. 그 후 카르마는 파일 시스템 변경을 검사해 이 내용을 저장한 후 모든 브라우저에서의 테스트 결과를 보여준다.
단점이라면 사용자가 원하는 테스트로 구성 파일을 미리 준비해두어야 한다는 점이다. 그 파일 자체는 매우 직관적이다. 카르마를 실행하면 기본 사항을 거쳐가며 필요에 따라 파일을 생성한다. 우선은 어떤 프레임워크를 사용 할 지부터 결정해야 한다.
![](http://files.itworld.co.kr/image/2014/03/karma.jpg)
카르마 자체는 테스트 프레임을 가리지 않고, 프레임워크를 처리하는 방법은 플러그인에 의존한다. 플러그인은 재스민(jasmine), 모카(Mocha), 큐유닛(QUnit) 등 대부분의 프레임워크용으로 지원한다. 만약 이들 중 하나를 사용하지 않는다면, 우선 Npm(노드.js를 위한 공식 패키지 관리자)에서 카르마 플러그인을 먼저 확인하라. 테스트 프레임워크용 플러그인이 없다면, 필요한 플러그인을 작성하거나 더 보편적인 프레임워크로 갈아타면 된다.
그 다음은 브라우저 구성 작업을 해야 한다. 카르마는 크롬, 파이어폭스, 인터넷 익스플로러, 오페라 등 설정한 모든 브라우저를 자동으로 실행한다. 추가로 팬텀JS(PhantomJS)나 슬리머JS(SlimerJS)로 헤드리스(headless) 환경에서 테스트할 수도 있다. 이걸로도 충분치 않다면 브라우저스택(BrowserStack)이나 소스(Sauce)로 묶어 가능한 모든 브라우저에서 테스트할 수도 있다.
가령 삼성 TV 브라우저를 테스트하고 싶다면, 기기에 브라우저가 설치돼 있고 네트워크에 접속돼 있는 한 직접 연결해 바로 테스트를 할 수도 있다. 단지 특정 포트에서 호스트 컴퓨터의 IP 주소로 찾아 들어가면 기타 테스트 재가동 등을 포함한 나머지 작업은 자동으로 진행된다.
브라우저를 선택한 후, 카르마가 어디서 파일을 찾을지 지정하라. 만약 순서가 중요하면, 하나씩 파일을 정렬할 수도 있지만 프로젝트를 이런 식으로 설정하는 것은 추천하고 싶지 않다. 대신 리콰이어JS(RequireJS)같은 툴을 활용해 개별 사용자 환경에 맞게 관리하라. 이런 식으로 src/**/*.js 와 test/**/*Spec.js 같은 것들만 포함시키면 그걸로 끝이다. 이제 원하는 대로 파일을 추가 삭제하고 구성 파일은 손대지 마라. 만약 **/*.js 보다 더 작은 해머가 필요하다면, 카르마가 자바스크립트 정규 표현을 이해하기 때문에 이를 한번 털어내고 계속 진행하면 된다.
기본적인 프로젝트로는 이 정도로 충분하다. 이제 카르마가 파일 시스템 변경을 관찰하고, 카르마를 시작 실행하고 테스트 작성을 시작하면 된다.
작업을 위한 더 많은 툴
백본 애플리케이션(특히 템플릿에 관해서)을 테스팅 할 때 사용하는 구성 사양은 다양하고 거기에 또 도움이 될만한 추가 플러그인과 툴도 많다. 그 중 몇 가지를 소개한다.
필자는 재스민을 테스트 프레임워크로 사용한다. BDD 스타일은 내 눈에 잘 들어오고 높은 단계에서 테스트 상황을 추적하는데 도움을 준다. 재스민은 DOM-프리 이기 때문에, HTML에 관해 테스트할 때 재스민-제이쿼리(jasmine-jquery)를 활용하고 싶을 것이다. 이는 재스민이 다양한 종류의 DOM-특정 어서션(assertion)을 포함하고 HTML과 JSON 픽스쳐 로딩 지원을 추가시킨다.
어서션에 관해 이야기할 때, 만약 Node.js 코드를 작성하거나 오직 현대적 브라우저만을 대상으로 할 경우에는 should.js를 진지하게 살펴봐야 한다. 이를 이용하면 어서션 라이브러리로 재스민과 조화롭게 작동하고 깔끔하게 읽힌다. 유일한 문제는 ECMA스크립트 접근자 속성(게터와 세터)을 사용해 인터넷 익스플로러 8과 그 이전 버전 등의 몇몇 브라우저에서 지원하지 않는다는 점이다.
재스민이 목스(mocks)와 스파이스(spies)처럼 많은 테스팅 능력을 제공하지만, XHR 요청을 속이는 능력 지원은 최근에야 시작됐다. 이 새로운 지원은 아직 성숙이 필요하므로 지금까지 써오던 sinon.js를 고수하면서 서버를 대신하게 하겠다. Sinon.js는 수많은 재스민의 기능성과 겹치지만 서버를 한동안 속일 수 있는 능력을 보유해왔고 설정과 사용도 간편하다.
필자가 한 모든 테스팅은 코드가 커버됐는지를 확인하는 것이 목적이다. 필자는 카르마 플러그인을 이스탄불(istanbul) 코드 커버리지 툴로 활용한다. Esprima와 escodegen을 기반으로 구축된 이스탄불은 카르마와 아주 잘 작동한다. 그 자체만으로 이스탄불은 HTML과 LCOV로 보고서를 만들어내지만 카르마 플러그인은 텍스트 아웃풋과 Cobertura XML 지원을 더해주기 때문에 젠킨스(Jenkins)가 이해할 수 있다. 그렇다. 카르마는 지속 통합 툴을 위한 플러그인 역시 지원한다.
![](http://files.itworld.co.kr/image/2014/03/istanbul.jpg)
모두 합쳐져 이 툴들은 필자의 시간 소모와 두통을 상당히 줄여주었다. 만약 자바스크립트 유닛 테스팅이나 현재 테스팅 작업흐름 업그레이드에 관심이 있다면, 하루 이틀 정도 이런 툴들을 시험삼아 써본 후 개별 환경에 맞는 것을 찾아 사용해 보자.
※ 본 내용은 한국IDG(주)(http://www.itworld.co.kr)의 저작권 동의에 의해 공유되고 있습니다.
Copyright ⓒITWORLD. 무단전재 및 재배포 금지
[원문출처 : http://www.itworld.co.kr/news/86538]
번호 | 제목 | 조회수 | 작성 |
---|---|---|---|
공지 | [Open UP 활용가이드] 공개SW 활용 및 개발, 창업, 교육 "Open UP을 활용하세요" | 316068 | 2020-10-27 |
공지 | [Open UP 소개] 공개SW 개발·공유·활용 원스톱 지원 Open UP이 함께합니다 | 305659 | 2020-10-27 |
2801 | 더 나은 자바스크립트 테스팅을 위한 가이드 | 4104 | 2014-03-18 |
2800 | 삼성, 웨어러블용 타이젠 SDK 발표…기어 2용 앱 생태계 강화 | 3886 | 2014-03-18 |
2799 | [주간 클라우드 동향] 아마존에선 ‘클라우드’ 용어 안 쓴다? | 4149 | 2014-03-18 |
2798 | 삼성전자 타이젠폰 출시 연기 왜… 안드로이드 OS 압박에 한발 물러서 | 4036 | 2014-03-18 |
2797 | 모바일 '친화적인' 웹사이트 구축 팁 12선 | 4775 | 2014-03-18 |
2796 | 크라이텍, 앞으로 크라이엔진은 리눅스도 지원할 것이라 밝혀 | 4477 | 2014-03-18 |
2795 | “진짜 성과내는 빅데이터 연합 만들겠다“ | 3550 | 2014-03-18 |
2794 | 구글-애플 OS 천하, 아시아서 흔들리나 | 3735 | 2014-03-18 |
2793 | “한국인들 낯선 ‘소프트웨어 아트’에 놀라운 관심” | 4366 | 2014-03-17 |
2792 | "깃허브 여성 차별 심해"…퇴사자 폭로 | 3953 | 2014-03-17 |
0개 댓글