이 글은 마이크로소프트웨어 에 2013년 10월 기고한 내용입니다.
프론트엔드에서 자동화된 테스팅의 역사가 짧은 만큼, 상대적으로 어떻게 프론트엔드 어플리케이션을 테스트할 수 있는지에 대해서는 전반적으로 이해가 부족한 편이다. 그래서인지 꽤 많은 프론트엔드 개발자들이 테스트를 생각할 때 머뭇거리는 것이 사실이다.
테스트 환경은 어떻게 세팅할 수 있을까? 어떻게 runner를 설정하고, 어떻게 과정을 자동화할 수 있을까? nodeJS를 사용해서 어떻게 환경을 설정하는걸까? PhantomJS나 Headless Webkit과 같은 숨겨진 브라우저는 어떤걸까? 모든 다양한 브라우저 상에서 직접 테스트를 실행해야 할까? 테스트를 작성할 때 어떤 부분을 해야할까? 어떻게 spec들을 작성할 수 있을까? 답이 필요한 질문들이 이렇게나 많다. 프론트엔드에서 테스팅이 까다롭고 성가신 일이라는걸 깨닫는 데에는 오랜 시간이 걸리지 않는다. 여기에서는 처음부터 벽에 막히는 것 같은 AngularJS 어플리케이션 테스트 방법에 대해 기초 이론부터 실습까지 차근차근 다뤄보고자 한다.
프론트엔드에서 자동화된 테스팅의 역사가 짧은 만큼, 상대적으로 어떻게 프론트엔드 어플리케이션을 테스트할 수 있는지에 대해서는 전반적으로 이해가 부족한 편이다. 그래서인지 꽤 많은 프론트엔드 개발자들이 테스트를 생각할 때 머뭇거리는 것이 사실이다.
테스트 환경은 어떻게 세팅할 수 있을까? 어떻게 runner를 설정하고, 어떻게 과정을 자동화할 수 있을까? nodeJS를 사용해서 어떻게 환경을 설정하는걸까? PhantomJS나 Headless Webkit과 같은 숨겨진 브라우저는 어떤걸까? 모든 다양한 브라우저 상에서 직접 테스트를 실행해야 할까? 테스트를 작성할 때 어떤 부분을 해야할까? 어떻게 spec들을 작성할 수 있을까? 답이 필요한 질문들이 이렇게나 많다. 프론트엔드에서 테스팅이 까다롭고 성가신 일이라는걸 깨닫는 데에는 오랜 시간이 걸리지 않는다. 여기에서는 처음부터 벽에 막히는 것 같은 AngularJS 어플리케이션 테스트 방법에 대해 기초 이론부터 실습까지 차근차근 다뤄보고자 한다.
테스트의 종류
AngularJS에서 테스트는 크게 두 종류로 나눌 수 있고 추가적으로 한 가지 개념이 더 언급되고 있다. AngularJS는 기본적으로 단위(Unit) 테스트와 E2E(End to End) 테스트를 제공해주고 있고 적용하려는 테스트 방법에 따라 약간 다른 설정이 각각 요구된다. 단위 테스트는 독립된 작은 코드의 '단위들'에 의해 동작하기 떄문에 다각도에서 테스트가 수행될 수 있지만, 반면에 E2E 테스트는 어플리케이션의 전반적인 영역에서 테스트가 이루어지기 때문에 End to End라고 불려진다. AngularJS의 좋은 점은 이러한 E2E테스트들이 시나리오 러너(Scenario Runner)를 사용함으로써 완전하게 갖춰져 있다는 점이다. 이 두 가지 테스트 방법에 대해 간단하게 정리하면 아래와 같다.
위에 언급한 단위 테스트와 E2E 테스트 외에도 이 둘의 중간쯤에 위치하는 Midway 테스팅도 존재한다. 단위테스트를 수행할 때, request들과 임시 작업을 만들기 위해 인터셉터들과 목(mock)이 필요하기 때문에 어플리케이션 수준의 동작을 테스트할 때는 때때로 테스트를 준비하는 것 자체가 너무 복잡해질 수 있다. E2E 테스트 또한 항상 최선은 아니다. 왜냐하면 이 테스트는 너무 상위 레벨이기 때문에 특정한 기능을 테스트하기에는 어려움이 있다. 예를 들어 매 페이지마다 사용자의 세션을 다운로드하는 XHR 요청을 수행하는 웹 사이트의 컨트롤러를 테스트하는 것을 들 수 있다. 이런 경우 E2E로 테스트가 거의 불가능하다. 왜냐하면 Scope의 멤버와 어플리케이션 레벨의 자바스크립트 코드에 접근하는 것이 까다롭기 때문이다. 단위테스트는 또 오히려 테스트를 위해 더 많은 코드와 복잡성을 갖게 하는 너무 많은 목킹과 가짜 데이터가 필요하다. 그래서 이 둘 사이쯤에 위치하는 Midway 테스팅이 요구되기도 한다.
여기에서는 지면 관계상 가장 널리 알려진 단위 테스트와 E2E 테스트만을 다루기로 한다.
그럼 이제부터 카르마를 활용한 AngularJS 테스팅 방법에 대해서 알아보도록 하자.
https://github.com/eu81273/angularjs-testing-example.git
이번 연재를 위해 AngularJS Seed 를 기반으로 테스팅을 실습해볼 수 있도록 GitHub 프로젝트를 생성했다. 위의 GitHub 프로젝트에 들어가서 오른쪽 하단의 Download Zip 버튼을 눌러 프로젝트를 다운로드 받아서 C:\angularjs-testing-example 과 같이 임의의 폴더에 압축을 풀어두자.
NodeJS 설치가 마무리되었다면, 시작메뉴 – Node.js - Node.js command prompt 를 실행해서 커맨드창을 열고 아래의 명령을 입력하면 Karma를 쉽게 설치할 수 있다.
위의 명령을 입력하면 Karma 관련 데이터를 다운로드 받아 설치하는 것을 커맨드창을 통해 확인할 수 있다. 설치가 끝났다면 이제 테스트를 시작하기 위한 준비가 거의 완료되었다. 테스트를 하기 위해서는 브라우저 설정이 필요한데, 여기에서는 편의를 위해 크롬 브라우저가 설치되어 있다고 가정하고 Karma가 크롬 브라우저를 인식할 수 있도록 경로 지정을 해주도록 하겠다. 먼저 아래와 같이 환경변수에 접근한다.
test.bat 파일은 내부적으로 “karma start config\karma.conf.js” 라는 커맨드를 실행하는데, 이는 카르마 설정 파일에 따라 카르마를 시작하라는 의미이다. 정상적으로 실행되었다면, 자동으로 크롬 브라우저가 실행되어 아래와 같은 화면이 나타날 것이다.
또 커맨드창을 자세히 살펴보면 마지막에 Excuted 6 of 6 (2 FAILED) 라고 출력되어 있는데, 이미 설정해 놓은 6개의 테스팅 중 4개만 정상적으로 수행되었다는 의미이다.
이제 단위 테스트를 위한 모든 환경이 세팅되었다. 앞서 카르마가 실행될 때 카르마 설정 파일에 따라 실행된다고 설명했는데, 카르마 설정 파일의 구조에 대해 간단하게 살펴보자.
단위 테스트를 위한 카르마 설정 파일
단위 테스트를 위한 카르마 설정 파일은 위와 같은 구조로 되어 있다. 기본적으로 module화 되어 있는 구조임이 눈에 먼저 들어온다. Frameworks 항목에는 현재 Jasmine 으로 단위 테스트를 하도록 되어 있는데, 여기를 수정함으로써 mocha.js 등으로 단위테스트를 수행할 수 있다. 그 아래에 files 항목이 있는데 여기에서는 테스트를 수행할 때 불러와야 하는 스크립트 파일들을 명시하고 있다. 기본적으로 AgularJS 부터 시작해서 테스트할 모듈, 서비스 필터 등이 있는 app/js 폴더 하위의 모든 js 파일을 가져오고 있고, 테스트할 스펙이 담겨 있는 test/unit 폴더 아래의 모든 js 파일일을 가져오는 것을 볼 수 있다. 마지막으로 눈여겨 봐야하는 항목은 autoWatch 인데, 이 옵션을 true로 놓을 경우 로드된 js 파일들을 수정하면 바로 알아채고 다시 테스트를 자동으로 수행하게 된다.
이번 프로젝트에서는 단위 테스트를 위한 도구로 Jasmin을 사용하는데, Jasmine은 Behavior Driven Development Framework 로써 자바스크립트 코드를 테스트하는데 사용되는 타 프레임워크에 대한 종속성이 없는 독립적인 테스트 프레임워크이다. Jasmine 에 대한 보다 자세한 설명은 Jasmine 홈페이지(http://pivotal.github.io/jasmine/)에서 얻을 수 있다.
이제 본격적으로 단위 테스트를 하나하나 진행해 보자.
서비스의 가장 단순한 형태인 값을 저장하고 있는 서비스이다. 이러한 서비스가 정상적으로 동작하는지 확인하기 위한 테스트는 아래와 같은 예로 작성될 수 있다.
이와 같이 수정한 내용이 즉각적으로 반영되고 확인되기 때문에, 테스트 스펙 작성 후 소스 코딩이 진행될 때마다 단위 테스트를 수행하게 됨으로써 짧은 개발 사이클을 반복적으로 수행하는 것을 기본으로 하는 테스트 주도 개발에 근접할 수 있다.
서비스와 연계해서 app-version 지시어가 있으면 해당 부분에 version값을 넣어주는 형태이다. 이러한 지시자에 대한 테스트는 아래와 같이 설계하게 된다.
필터나 서비스 등에 비해 다소 복잡한 구조임을 볼 수 있다. 하지만 자세히 살펴보면 복잡하지 않다. 먼저 module을 통해 차후 결과 비교를 위한 version 값을 가져온 후에, 아래에서 $compile과 $rootScope을 인젝션 받아서 지시자가 포함된 문자열 “<span app-version></span>” 를 컴파일 한다. 이 컴파일 된 결과값이 앞서 미리 결과 비교를 위해 저장해둔 version 값과 같은지를 테스트하는 형태이다.
%VERSION% 이라고 되어 있는 부분을 version 서비스의 값으로 치환해주는 단순한 필터임을 볼 수 있다. 이러한 필터에 대한 테스트는 아래와 같이 설계할 수 있다.
이번 테스트에서는 조금 특별하게 먼저 필터 자체가 먼저 존재하는지 여부를 테스트하고 있다. 그 후에 '앞 %VERSION% 뒤' 라는 문자열에 필터를 적용하고 그 결과가 일치하는지를 확인하고 있다.
컨트롤러 파일에는 각각 test1 에 ‘ABC’ 라는 문자열을 담고, test2에 ‘안녕하세요!’를 반환하는 함수를 담은 것을 볼 수 있다. 컨트롤러에 대한 테스트 스펙을 설정하는 것은 다른 부분에 대해서 까다로운 편인데 차근차근 살펴보자.
| 단위 테스트(Unit Testing) | E2E 테스트(E2E Testing) |
| 코드 레벨 테스팅 서비스나 클래스, 오브젝트 테스트에 적합 샌드박스 및 독립 테스트에 적합 외부적 요소에 대해 Mocking과 Stubbing 필요 빠름 |
웹 레벨 테스팅 별도의 특별한 웹서버 필요 통합 테스트에 적합 자바스크립트 코드에 직접 접근할 수 없고 렌더링된 HTML과 약간의 AngularJS 정보에만 접근 가능 느림 |
위에 언급한 단위 테스트와 E2E 테스트 외에도 이 둘의 중간쯤에 위치하는 Midway 테스팅도 존재한다. 단위테스트를 수행할 때, request들과 임시 작업을 만들기 위해 인터셉터들과 목(mock)이 필요하기 때문에 어플리케이션 수준의 동작을 테스트할 때는 때때로 테스트를 준비하는 것 자체가 너무 복잡해질 수 있다. E2E 테스트 또한 항상 최선은 아니다. 왜냐하면 이 테스트는 너무 상위 레벨이기 때문에 특정한 기능을 테스트하기에는 어려움이 있다. 예를 들어 매 페이지마다 사용자의 세션을 다운로드하는 XHR 요청을 수행하는 웹 사이트의 컨트롤러를 테스트하는 것을 들 수 있다. 이런 경우 E2E로 테스트가 거의 불가능하다. 왜냐하면 Scope의 멤버와 어플리케이션 레벨의 자바스크립트 코드에 접근하는 것이 까다롭기 때문이다. 단위테스트는 또 오히려 테스트를 위해 더 많은 코드와 복잡성을 갖게 하는 너무 많은 목킹과 가짜 데이터가 필요하다. 그래서 이 둘 사이쯤에 위치하는 Midway 테스팅이 요구되기도 한다.
여기에서는 지면 관계상 가장 널리 알려진 단위 테스트와 E2E 테스트만을 다루기로 한다.
카르마(Karma) - AngularJS 를 위한 테스팅툴
자바스크립트 테스트를 시작할 때 직면하는 가장 큰 어려움 중 하나는 작성한 코드를 테스트하기 위한 러너(Runner)를 셋업해야 한다는 사실이다. 자바스크립트 러너에 작성한 어플리케이션의 소스와 테스트를 포함한 코드를 어떻게 테스트 도구와 연결할 때의 어려움은 처음 자바스크립트 테스트를 해보려는 사람의 의지를 꺾을 때가 많다.
일반적으로 테스팅 툴을 사용한다면, 각 브라우저들을 모두 열고 모든 스펙들이 에러 없이 잘 돌아가는지 테스트하거나 테스트 도구를 호출할 커맨드라인 프로그램을 실행하게 될 것이다. 만약 커맨드라인에서 테스트 도구를 실행한다면 테스트 도구에 자동화된 브라우저 테스터를 작성해야 하고 이건 약간의 트릭이 필요해진다. 이렇게 고통스럽고 많은 시간과 노력을 잡아먹는 테스트 설정 과정은 어플리케이션 개발과 같은 보다 중요한 것들을 위해 간편화 될 필요가 있다.
카르마는 자바스크립트 코드를 테스트할 때, 또 테스트 러너 작동을 설정할 때의 모든 번거로운 부분을 처리해 주도록 설계된 놀라운 테스팅 툴이다. 설정 파일에 따라 각 브라우저를 열어서 자바스크립트 코드를 실행하고 브라우저에서는 특정한 테스트들을 통과하는지 볼 수 있다. 카르마와 각 브라우저 사이의 통신은 socket.io를 사용한 터미널에서 돌아가는 카르마 서비스를 통해 이뤄지는데, 테스트가 작동할 때마다 카르마는 어떤 브라우저가 각 테스트에서 실패하고 통과하는지 상태를 기록하고, 시간은 얼마나 걸리는지 계산해주며, 각각 따로 테스트할 필요 없이 각 브라우별로 한번에 테스트를 수행한다. 게다가 매우 빠르기까지 하다.
테스트 환경 구성
그럼 이제 각 테스트 환경을 설정해보도록 하자. 이번 연재의 각 테스트들을 수행해보려면 미리 준비된 아래의 예제 프로젝트를 다운로드 하는 것이 좋다.
① 예제 프로젝트 다운로드
https://github.com/eu81273/angularjs-testing-example.git
이번 연재를 위해 AngularJS Seed 를 기반으로 테스팅을 실습해볼 수 있도록 GitHub 프로젝트를 생성했다. 위의 GitHub 프로젝트에 들어가서 오른쪽 하단의 Download Zip 버튼을 눌러 프로젝트를 다운로드 받아서 C:\angularjs-testing-example 과 같이 임의의 폴더에 압축을 풀어두자.
② NodeJS 설치
Karma는 NodeJS를 기반으로 하기 때문에 http://nodejs.org/ 에서 NodeJS를 설치하도록 한다.
NodeJS 설치가 마무리되었다면, 시작메뉴 – Node.js - Node.js command prompt 를 실행해서 커맨드창을 열고 아래의 명령을 입력하면 Karma를 쉽게 설치할 수 있다.
npm install –g karma
위의 명령을 입력하면 Karma 관련 데이터를 다운로드 받아 설치하는 것을 커맨드창을 통해 확인할 수 있다. 설치가 끝났다면 이제 테스트를 시작하기 위한 준비가 거의 완료되었다. 테스트를 하기 위해서는 브라우저 설정이 필요한데, 여기에서는 편의를 위해 크롬 브라우저가 설치되어 있다고 가정하고 Karma가 크롬 브라우저를 인식할 수 있도록 경로 지정을 해주도록 하겠다. 먼저 아래와 같이 환경변수에 접근한다.
환경변수에서 변수 이름은 “CHROME_BIN”으로 변수값은 각자의 크롬브라우저 절대경로를 입력해준다. 예를 들어 Windows7 64비트 버전을 기준으로 아래와 같은 경로를 갖는다.
C:\Program Files (x86)\Google\Chrome\Application\chrome.exe
단위 테스트 준비
이제 테스트를 수행하기 위한 모든 준비가 완료되었다. 앞서 다운로드 받아 압축을 풀어두었던 프로젝트 폴더의 하위 폴더 중 하나인 scripts 폴더에서 test.bat 파일을 실행하면 단위 테스트가 시작된다!
test.bat 파일은 내부적으로 “karma start config\karma.conf.js” 라는 커맨드를 실행하는데, 이는 카르마 설정 파일에 따라 카르마를 시작하라는 의미이다. 정상적으로 실행되었다면, 자동으로 크롬 브라우저가 실행되어 아래와 같은 화면이 나타날 것이다.
또 커맨드창을 자세히 살펴보면 마지막에 Excuted 6 of 6 (2 FAILED) 라고 출력되어 있는데, 이미 설정해 놓은 6개의 테스팅 중 4개만 정상적으로 수행되었다는 의미이다.
이제 단위 테스트를 위한 모든 환경이 세팅되었다. 앞서 카르마가 실행될 때 카르마 설정 파일에 따라 실행된다고 설명했는데, 카르마 설정 파일의 구조에 대해 간단하게 살펴보자.
단위 테스트를 위한 카르마 설정 파일
module.exports = function (karma) {
karma.set({
frameworks: ['jasmine'],
files: [
'app/lib/angular/angular.js',
'app/lib/angular/angular-*.js',
'test/lib/angular/angular-mocks.js',
'app/js/**/*.js',
'test/unit/**/*.js'
],
basePath: '../',
exclude: [],
reporters: ['progress'],
port: 8080,
runnerPort: 9100,
colors: true,
autoWatch: true,
browsers: ['Chrome'],
singleRun: false
});
};
config/karma.conf.js 파일
단위 테스트를 위한 카르마 설정 파일은 위와 같은 구조로 되어 있다. 기본적으로 module화 되어 있는 구조임이 눈에 먼저 들어온다. Frameworks 항목에는 현재 Jasmine 으로 단위 테스트를 하도록 되어 있는데, 여기를 수정함으로써 mocha.js 등으로 단위테스트를 수행할 수 있다. 그 아래에 files 항목이 있는데 여기에서는 테스트를 수행할 때 불러와야 하는 스크립트 파일들을 명시하고 있다. 기본적으로 AgularJS 부터 시작해서 테스트할 모듈, 서비스 필터 등이 있는 app/js 폴더 하위의 모든 js 파일을 가져오고 있고, 테스트할 스펙이 담겨 있는 test/unit 폴더 아래의 모든 js 파일일을 가져오는 것을 볼 수 있다. 마지막으로 눈여겨 봐야하는 항목은 autoWatch 인데, 이 옵션을 true로 놓을 경우 로드된 js 파일들을 수정하면 바로 알아채고 다시 테스트를 자동으로 수행하게 된다.
이번 프로젝트에서는 단위 테스트를 위한 도구로 Jasmin을 사용하는데, Jasmine은 Behavior Driven Development Framework 로써 자바스크립트 코드를 테스트하는데 사용되는 타 프레임워크에 대한 종속성이 없는 독립적인 테스트 프레임워크이다. Jasmine 에 대한 보다 자세한 설명은 Jasmine 홈페이지(http://pivotal.github.io/jasmine/)에서 얻을 수 있다.
이제 본격적으로 단위 테스트를 하나하나 진행해 보자.
단위 테스트 – 서비스
먼저 가장 간단한 구조인 서비스를 살펴봄으로써 어떠한 구조로 단위테스트가 이루어지는지 살펴보자.
/* 서비스 */
angular.module('myApp.services', []).
//버전값
value('version', '0.1');
app/js/services.js 파일
서비스의 가장 단순한 형태인 값을 저장하고 있는 서비스이다. 이러한 서비스가 정상적으로 동작하는지 확인하기 위한 테스트는 아래와 같은 예로 작성될 수 있다.
// 서비스 단위 테스트
describe('서비스 단위 테스트', function() {
beforeEach(module('myApp.services'));
describe('버전 서비스 테스트', function() {
it('현재 버전 반환', inject(function(version) {
expect(version).toEqual('0.1');
}));
});
});
test/unit/servicesSpec.js 파일
매우 간단한 구조이다. descibe 는 하나의 suite 으로 중첩될 수 있다. 그 아래에 각 테스트마다 수행할 전처리인 beforeEach 에서 서비스 모듈을 넣어준 후에 it 에서 version 서비스를 인젝션 받고 있는 것을 볼 수 있다. 그 아래에서 version 이 0.1과 같은지를 테스트하고 있다.
expect(version).toEqual('0.1'); 라고 되어 있는 부분을 expect(version).toEqual('33'); 으로 바꾼 후 저장하면 아래와 같이 커맨드창에 테스트 실패가 하나 늘어난 것을 볼 수 있다.
이와 같이 수정한 내용이 즉각적으로 반영되고 확인되기 때문에, 테스트 스펙 작성 후 소스 코딩이 진행될 때마다 단위 테스트를 수행하게 됨으로써 짧은 개발 사이클을 반복적으로 수행하는 것을 기본으로 하는 테스트 주도 개발에 근접할 수 있다.
테스트 스펙 파일의 구조
서비스에 대한 단위 테스트를 살펴보며 기본적인 스펙 파일의 구조를 살펴보았다. 좀더 구체적으로 살펴보면, Jasmine 테스트 스펙 파일은 아래와 같은 형태를 갖는다. 다른 언어들의 것과 크게 다르지 않은 모습을 볼 수 있다. 물론 실제 활용시 전처리 및 후처리가 모두 있어야 하는 것은 아님을 기억하자.
describe('테스트 대상 설명', function() {
// 테스트 전처리
before(function() {
});
// 테스트 후처리
after(function() {
});
// it 마다 매번 실행하는 전처리
beforeEach(function() {
});
// it 마다 매번 실행하는 후처리
afterEach(function() {
});
it('테스트 내용 설명', function() {
// 테스트
});
it('테스트 내용 설명', function() {
// 테스트
});
});
단위 테스트 – 지시자
지시자는 AngularJS 어플리케이션의 주요 컴포넌트로 중요한 테스트 중 하나이다. 지시자를 테스트할 때 일반적으로 지시자가 정상적으로 실행되어서 원하는 형태의 값이나 DOM으로 변경되었는지를 체크하게 된다. 지시자 내부에서 XHR 요청을 하는 경우도 있지만 여기에서는 그 부분까지는 실습하지는 않기로 한다.
먼저 지시자가 어떠한 구조로 되어 있는지 확인해보자.
/* 지시자 */
angular.module('myApp.directives', []).
//app-version 지시자 위치에 앱 버전을 표시해준다.
directive('appVersion', ['version', function(version) {
return function(scope, elm, attrs) {
elm.text(version);
};
}]);
app/js/directives.js 파일
서비스와 연계해서 app-version 지시어가 있으면 해당 부분에 version값을 넣어주는 형태이다. 이러한 지시자에 대한 테스트는 아래와 같이 설계하게 된다.
/* 지시자 단위 테스트 */
describe('지시자 단위 테스트', function() {
beforeEach(module('myApp.directives'));
describe('app-version 지시자 테스트', function() {
it('현재 버전 출력', function() {
module(function($provide) {
$provide.value('version', 'TEST_VER');
});
inject(function($compile, $rootScope) {
var element = $compile('<span app-version></span>')($rootScope);
expect(element.text()).toEqual('TEST_VER');
});
});
});
});
test/unit/directivesSpec.js 파일
필터나 서비스 등에 비해 다소 복잡한 구조임을 볼 수 있다. 하지만 자세히 살펴보면 복잡하지 않다. 먼저 module을 통해 차후 결과 비교를 위한 version 값을 가져온 후에, 아래에서 $compile과 $rootScope을 인젝션 받아서 지시자가 포함된 문자열 “<span app-version></span>” 를 컴파일 한다. 이 컴파일 된 결과값이 앞서 미리 결과 비교를 위해 저장해둔 version 값과 같은지를 테스트하는 형태이다.
단위 테스트 – 필터
AngularJS 필터를 테스트할 때는, 테스트하고자 하는 필터를 injection 해준 후에 호출하는 방식으로 진행된다. 먼저 테스트할 필터 모듈을 살펴보자.
/* 필터 */
angular.module('myApp.filters', []).
//%VERSION% 위치에 버전을 표시해준다.
filter('interpolate', ['version', function(version) {
return function(text) {
return String(text).replace(/\%VERSION\%/mg, version);
}
}]);
app/js/filters.js 파일%VERSION% 이라고 되어 있는 부분을 version 서비스의 값으로 치환해주는 단순한 필터임을 볼 수 있다. 이러한 필터에 대한 테스트는 아래와 같이 설계할 수 있다.
/* 필터 단위 테스트 */
describe('필터 단위 테스트', function() {
beforeEach(module('myApp.filters'));
describe('interpolate 필터 테스트', function() {
beforeEach(module(function($provide) {
$provide.value('version', 'TEST_VER');
}));
it('interpolate 필터 존재', inject(function(interpolateFilter) {
expect(interpolateFilter).not.toEqual(null);
}));
it('VERSION 위치에 치환', inject(function(interpolateFilter) {
expect(interpolateFilter('앞 %VERSION% 뒤')).toEqual('앞 TEST_VER 뒤');
}));
});
});
test/unit/filtersSpec.js 파일이번 테스트에서는 조금 특별하게 먼저 필터 자체가 먼저 존재하는지 여부를 테스트하고 있다. 그 후에 '앞 %VERSION% 뒤' 라는 문자열에 필터를 적용하고 그 결과가 일치하는지를 확인하고 있다.
단위 테스트 – 컨트롤러
컨트롤러를 테스트하는 것은 스콥(Scope)을 통해 어떤 데이터가 컨트롤러로부터 템플릿에 전달되는지에 대한 이해가 필요하다. 그렇게 때문에 먼저는 컨트롤러 자체가 정상적으로 동작하는지 테스트한 후에 데이터가 템플릿에 반영될 수 있을 것이다. 컨트롤러에 대한 단위테스트는 E2E 테스트와는 달리 컨트롤러의 로직에 전적으로 종속적이다. E2E테스트의 경우에는 컨트롤러가 모든걸 정확하게 처리하는지 보장할 수 없기 때문에 비교적 컨트롤러 테스트에는 Midway Test 가 권장되는 편이다. 테스트할 컨트롤러를 살펴보자.
/* 컨트롤러 */
angular.module('myApp.controllers', []).
//view1의 컨트롤러
controller('MyCtrl1', ['$scope', function($scope) {
$scope.test1 = 'ABC';
}])
//view2의 컨트롤러
.controller('MyCtrl2', ['$scope', function($scope) {
$scope.test2 = function() {
return '안녕하세요!';
};
}]);
app/js/controllers.js 파일컨트롤러 파일에는 각각 test1 에 ‘ABC’ 라는 문자열을 담고, test2에 ‘안녕하세요!’를 반환하는 함수를 담은 것을 볼 수 있다. 컨트롤러에 대한 테스트 스펙을 설정하는 것은 다른 부분에 대해서 까다로운 편인데 차근차근 살펴보자.
/* 컨트롤러 단위 테스트 */
describe('controllers 단위 테스트', function(){
beforeEach(module('myApp.controllers'));
var scope;
it('MyCtrl1 컨트롤러 test1값', inject(function($rootScope, $controller) {
scope = $rootScope.$new();
var ctrl = $controller('MyCtrl1', {
$scope : scope
});
expect(scope.test1).toBe('EFG');
}));
it('MyCtrl2 컨트롤러 test2값', inject(function($rootScope, $controller) {
scope = $rootScope.$new();
var ctrl = $controller('MyCtrl2', {
$scope : scope
});
expect(scope.test2()).toBe('안녕히계세요!!');
}));
});
test/unit/controllersSpec.js 파일
먼저 각 테스트마다 기본적으로 'myApp.controllers' 모듈을 가져오고, $scope을 새로 생성하기 위해 $rootScope 과 컨트롤러를 생성하기 위해 $controller 를 인젝션해주는 것을 볼 수 있다. 컨트롤러 내부의 $scope에 접근하기 위해 외부에서 선언해준 scope 변수를 $scope에 할당해준 후, 각각 $scope 안의 값이 기대값과 같은지를 테스트하도록 되어 있다. 그런데 위의 컨트롤러와는 다른 값으로 설계되어 있는데, 이로 인해 단위 테스트를 수행했을 때 2개의 실패가 있었다는 것을 알 수 있다. 따라서 컨트롤러 내부의 $scope 값을 설계한 테스트에서의 값과 동일하게 수정해주면 2개의 실패를 모두 잡아줄 수 있다.
컨트롤러 테스트를 마지막으로 AngularJS에서의 단위 테스트에 대해서 다소 간단한 예제를 통해 모두 짚어 보았다. 이번에는 좀더 큰 관점에서 테스트하는 E2E 테스트에 대해서 계속해서 살펴보자.
E2E 테스트를 위한 카르마 설정 파일
단위 테스트용 카르마 설정 파일과 E2E 테스트를 위한 카르마 설정 파일은 약간의 차이를 갖는다.E2E 테스트를 위한 카르마 설정 파일
module.exports = function (karma) {
karma.set({
frameworks: ['ng-scenario'],
files: [
'test/e2e/**/*.js'
],
basePath: '../',
exclude: [],
reporters: ['progress'],
port: 8000,
runnerPort: 9100,
colors: true,
autoWatch: true,
browsers: ['Chrome'],
singleRun: true,
urlRoot: '/_karma_/',
proxies: {
'/': 'http://localhost:8000/'
}
});
};
config/karma-e2e.conf.js 파일
E2E 테스트를 위한 카르마 설정 파일은 위와 같은 구조로 되어 있다. 기본적으로 단위 테스트용과 거의 비슷하지만, Jasmine이 아닌 ng-scenario를 프레임워크로 설정하고 있는 것과 그 아래에 files 항목 역시 e2e 폴더 아래의 js 파일만 가져온다는 것이 주요한 차이이다.
E2E 테스트 준비
E2E 테스트를 위해서는 config 파일뿐 아니라 config 파일에서 설정해 준 ng-scenario를 추가해주어야 한다. 다시 시작메뉴 – Node.js - Node.js command prompt 를 실행해서 커맨드창을 열고 아래의 명령을 입력하여 ng-scenario를 설치하자.
npm install -g karma-ng-scenario
웹서버가 위와 같이 실행됐다면, scripts 폴더로 이동해서 e2e-test.bat 파일을 실행하면 E2E 테스트를 수행하게 된다.
E2E 테스트는 너무 빠르게 실행된 후 종료되어서 제대로 실행되었는지 인지하지 못했을 수도 있다. 이렇게 빠르게 이루어지는 E2E 테스트 과정 중에 어떤 동작을 하는지 test/e2e/scenarios.js 파일을 살펴보자.npm install -g karma-ng-scenario
E2E 테스트는 또한 테스트를 위한 웹서버가 필요하다. 여기에서는 함께 제공된 web-server-start.bat 파일을 실행하면 web-server.js 파일을 node를 사용해서 웹서버를 실행하기로 한다.
/* E2E 테스트 */
describe('AngularJS 어플리케이션', function() {
beforeEach(function() {
browser().navigateTo('../../app/index.html');
});
it('특별한 해시값을 지정하지 않을 경우 자동으로 /view1으로 이동', function() {
expect(browser().location().url()).toBe("/view1");
});
describe('메뉴1 이동', function() {
beforeEach(function() {
browser().navigateTo('#/view1');
});
it('사용자가 /view1 로 이동할 경우 1번 페이지 렌더링', function() {
expect(element('[ng-view] p:first').text()).
toMatch(/1번 페이지/);
});
});
describe('메뉴2 이동', function() {
beforeEach(function() {
browser().navigateTo('#/view2');
});
it('사용자가 /view2 로 이동할 경우 2번 페이지 렌더링', function() {
expect(element('[ng-view] p:first').text()).
toMatch(/2번 페이지/);
});
});
});
간단하게 요약해보면, 메뉴1 혹은 메뉴 2로 이동했을 때 ng-view 안에 페이지가 의도한대로 변했는지를 포함된 문자열을 통해 확인하는 시나리오다. 이러한 시나리오를 더 발전시킨다면 어플리케이션 전체 관점에서 동작을 테스트할 수 있을 것이다.
마치며
지금까지 살펴본 것처럼 AngularJS 어플리케이션을 테스트하는 것이 생각만큼 어려운 일은 아니다. AngularJS의 E2E와 단위 테스트는 매우 견고하게 잘 짜여져 있고 상호간에 충돌 없이 잘 동작한다. 또한 카르마는 상당히 뛰어난 테스팅 툴임을 직접 실습해가며 확인해볼 수 있었다. 프론트엔드 개발 과정에서 자동화된 테스팅을 도입하는 것은 테스팅이 익숙치 않았던 개발자에게는 번거로운 일이 될 수도 있지만, 한편으론 테스팅에 이르기까지 잘 설계된 AngularJS 프레임워크의 진가를 더욱 느낄 수 있는 기회가 될 수도 있으리라 기대해본다.