잊지 않겠습니다.

이번에는 Controller입니다. Controller는 view에서의 사용자의 action에 따른 scenario가 정해지게 됩니다. scenario에 따른 test code를 작성해주는 것이 가장 좋은 test code가 됩니다.
* page가 처음 load되면 list가 호출되어 기본 Data가 Loading된다. (AsService.list()가 호출)
* search button을 click시, list() method가 호출된다. (AsService.list()가 호출)
* startDate/endDate 값이 변경되면 list method가 호출된다.
* save button을 click시, confirm box가 표시되며, input값이 모두 정상적으로 입력되어 있지 않다면 error가 표시된다.

첫 case부터 시작해보도록 하겠습니다.

page가 처음 load되면 list() method가 호출된다.

page가 처음 load되는 것은 controller가 처음 생성되는 것을 의미합니다. 이는 beforeEach()에 대한 test code가 필요한 것을 의미합니다. list가 호출이 될 때, REST API를 호출하는 것을 가정하고 있기 때문에 REST API의 응답에 대한 mock response를 넣어주는 것이 필요합니다.

controller를 생성하기 위한 beforeEach와 createController 의 코드는 다음과 같이 구성될 수 있습니다.

  beforeEach(inject(function ($controller, $rootScope, _DateService_, $httpBackend) {
    httpBackend = $httpBackend;
    scope = $rootScope.$new();
    DateService = _DateService_;
    controller = $controller;
    OmAsListCtrl = createController();
  }));

  var createController = function() {
    var response = {"ok":true,"message":"api call completed","date":1413173458673,"data":[{"request":"김요청자","operators":"","requestPhoneNumber":"0212342341","receiptDate":"2014-08-27","name":"오피스를 더 좋게 해주세요.","receiptionPhoneNumber":"03121342134","location":"없음","id":"30221","receiption":"김접수자","departments":"관리팀,건축팀,관제팀,기계팀,소방팀","department":"-","status":"접수"},{"request":"박네임","requestPhoneNumber":"01015263748","departmentId":"0401","receiptDate":"2014-05-05","name":"13층 환기 안됨","receiptionPhoneNumber":"01056781234","location":"13층","id":"6","receiption":"이성명","departments":"관리팀,기계팀","department":"관리팀","status":"민원완료"}]};
    httpBackend.when('GET', /\/fms-api\/om\/as\/list?\W*/).respond(response);
    var ctrl = controller('OmAsListCtrl', {
      $scope: scope
    });
    scope.$digest();
    httpBackend.flush();
    expect(scope.items.length).not.toBe(0);
    return ctrl;
  };

scope.items의 갯수를 확인하고, 정확히 데이터가 matching되고 있는 것을 확인하면 load의 test code는 완료됩니다.

search button을 click시, list() method가 호출된다.

list button을 click하는 것은 $scope.list()가 호출되는 것을 의미합니다. 호출후에 items의 갯수를 확인해보는 것이 가장 쉬운 확인 방법입니다. test를 보다 쉽게 작성하기 위해서 list를 호출하기 전에 items를 초기화 시켜버린 후에 list를 호출한 후의 값을 비교해보면 확실히 알 수 있을것입니다.

  it('search button을 click시, list() method가 호출된다.', function() {
    scope.items = [];
    var response = {"ok":true,"message":"api call completed","date":1413173458673,"data":[{"request":"김요청자","operators":"","requestPhoneNumber":"0212342341","receiptDate":"2014-08-27","name":"오피스를 더 좋게 해주세요.","receiptionPhoneNumber":"03121342134","location":"없음","id":"30221","receiption":"김접수자","departments":"관리팀,건축팀,관제팀,기계팀,소방팀","department":"-","status":"접수"},{"request":"박네임","requestPhoneNumber":"01015263748","departmentId":"0401","receiptDate":"2014-05-05","name":"13층 환기 안됨","receiptionPhoneNumber":"01056781234","location":"13층","id":"6","receiption":"이성명","departments":"관리팀,기계팀","department":"관리팀","status":"민원완료"}]};
    httpBackend.when('GET', /\/fms-api\/om\/as\/list?\W*/).respond(response);
    scope.list();
    httpBackend.flush();
    expect(scope.items.length).not.toBe(0);
  });

startDate/endDate값이 변경되면 list method가 호출된다.

이는 spyOn을 이용하면 쉽게 처리가 가능합니다. 다음과 같은 test code를 작성할 수 있습니다.

  it('startDate가 변경되면, list가 호출되어야지 된다.', function() {
    spyOn(scope, 'list');
    scope.searchItem.startDate = '2015-05-01';
    scope.$digest();
    expect(scope.list).toHaveBeenCalled();
  });

  it('endDate가 변경되면, list가 호출되어야지 된다.', function() {
    spyOn(scope, 'list');
    scope.searchItem.endDate = '2015-05-01';
    scope.$digest();
    expect(scope.list).toHaveBeenCalled();
  });

save button을 click시, confirm이 표시되고, confirm true인 경우에 AsService.regist method가 호출된다.

confirm, alert은 browser가 제공하는 base dialog method입니다. 만약에 우리가 test code를 실행할때마다 dialog가 나오고, 그걸 수동으로 눌러줘야지 된다면 이는 매우 걸리적 거리는 일이 됩니다. 따라서, 이 method들을 override 시킬 필요가 있습니다. angularJS는 이를 위해서 $window를 제공하고 있습니다. 우리가 $window.confirm, $window.alert method를 override 시켜서 사용하면 confirm에서 항상 true만 선택하게 할 수 있습니다.

  beforeEach(inject(function ($controller, $rootScope, _$routeParams_, _$location_, _$window_) {
    routeParams = _$routeParams_;
    routeParams.id = '10';
    scope = $rootScope.$new();
    controller = $controller;
    window = _$window_;
    window.confirm = function(message) {
      console.log(message);
      return true;
    };
  }));

routeParam의 값에 따라 다른 동작을 하는 controller의 테스트

위 scenario에 없는 parameter값에 따라 다른 동작을 하는 controller를 test하는 방법입니다. 이는 기본적으로 $routeParam에 값을 설정시키고 나서 controller를 생성시켜주면 됩니다. 다음과 같은 test code pattern을 적용하면 됩니다.

  function createCtrl(ymd, type) {
    if(ymd) {
      routeParams.ymd = ymd;
    }
    if(type) {
      routeParams.type = type;
    }

    ctrl = controller('EmDailymeterListCtrl', {
      $scope: scope,
      $routeParams: routeParams,
      Dailymeterservice: service
    });
    if(ymd == null || type == 'list') {
      httpBackend.expectGET(/\/fms-api\/em\/dailymeter\/list?\W*/).respond(200, {});
    } else {
      httpBackend.expectGET(/\/fms-api\/em\/dailymeter\/new?\W*/).respond(200, {});
    }
    scope.$digest();
    httpBackend.flush();
    return ctrl;
  }


Posted by Y2K
,

service (non-HTTP)

angularJS의 service code는 일반적으로 REST API에 대한 호출을 하고, 그 결과를 받는 것을 담당하지만, 값의 변경이나 특정값들의 display 형식으로의 변경등을 service로 만들어서, 코드의 응집력을 높일 수 있습니다. 섭씨온도를 화씨온도로 바꾸는 등의 계산 로직도 역시 이 영역에 들어가게 됩니다.

이러한 service code의 테스트는 다음 항목을 확인하면 됩니다.

input 값에 대하여 output 값이 예상대로 나왔는지. 
> toBe(value) 구문을 이용합니다.

기본적으로 matcher를 사용하는 것이 point입니다. 예상한 값을 기준으로 원하는 output이 정상적으로 나오는지를 확인하는 것이 좋습니다.

service (with HTTP)

REST API를 사용하는 service code의 테스트 방법에 대해서 알아보도록 하겠습니다. 일단 REST API를 호출한다면 외부의 HTTP resource를 이용하게 됩니다. 외부의 자원을 이용한다는 것은 그 외부의 자원에 대한 통제권은 우리가 개발한 application에는 없다는 말과 동일합니다. 따라서, 우리가 REST API를 이용하는 service에서 확인할 내용은 다음 두가지입니다.

* 원하는 URL로 정상적으로 호출하고 있는지?
* 전달하는 parameter가 API 호출 규약에 맞는지?

여기서 두가지의 역활이 나뉘게 됩니다. 먼저 원하는 URL로 호출하는 것은 당연히 service가 하는 일입니다. 그런데, 전달하는 parameter가 호출규약에 맞는지는 어떻게 확인하는 것이 좋을까요. 우리가 Spring을 이용한 개발을 진행하였을때를 생각해보면 쉽게 결론이 나옵니다. Validator객체를 만들어서 사용하는 것입니다.

따라서, REST API를 호출하는 service의 코드는 두개의 객체로 나뉘어지면 테스트 및 개발이 원활하게 됩니다. 이와 같은 형태는 마치 Spring MVC에서의 Controller 객체와 Validator 객체를 따로 개발하는 것과 동일한 패턴을 가지고 오게 됩니다. 객체지향이라는 것이 궁극적으로는 서로간에 할 일을 명확히 구분지어주고 그 분류대로 일을 진행하는 것이니까요.

먼저, 간단한 validator code는 다음과 같습니다.

'use strict';

/**
 * @ngdoc service
 * @name fmsmobilewebApp.ResultRegisterValidatorService
 * @description
 * # ResultRegisterValidatorService
 * Service in the fmsmobilewebApp.
 */
angular.module('fmsmobilewebApp').service('ResultRegisterValidatorService', function ResultRegisterValidatorService() {
  var self = this;

  self.validateStatus = function(data) {
    return angular.isDefined(data.status);
  };

  self.validateDepartment = function(data) {
    return angular.isDefined(data.departmentId);
  };

  self.validateOpResult = function(data) {
    var checked = angular.isDefined(data.opResult) &&
                  angular.isDefined(data.opResult.content) &&
                  angular.isDefined(data.opResult.startDate) &&
                  angular.isDefined(data.opResult.endDate);
    return checked;
  };
});

그리고 이에 대한 테스트 코드는 다음과 같습니다.

'use strict';

describe('Service: ResultRegisterValidatorService', function () {

  // load the service's module
  beforeEach(module('fmsmobilewebApp'));

  // instantiate service
  var service;
  beforeEach(inject(function (_ResultRegisterValidatorService_) {
    service = _ResultRegisterValidatorService_;
  }));

  it('validate for opResult', function() {
    var data = {};
    expect(service.validateOpResult(data)).toBe(false);
    data.opResult = {};
    expect(service.validateOpResult(data)).toBe(false);
    data.opResult.content = 'Content';
    expect(service.validateOpResult(data)).toBe(false);
    data.opResult.startDate = '2014-04-05 12:00';
    expect(service.validateOpResult(data)).toBe(false);
    data.opResult.endDate = '';
    expect(service.validateOpResult(data)).toBe(true);
  });

  it('validate for status', function() {
    var data = {};
    expect(service.validateStatus(data)).toBe(false);
    data.status = '0701';
    expect(service.validateStatus(data)).toBe(true);
  });

  it('validate for department', function() {
    var data = {};
    expect(service.validateDepartment(data)).toBe(false);
    data.departmentId = '0401';
    expect(service.validateDepartment(data)).toBe(true);
  });

});

Validator의 test code의 경우에는 기본적인 service code와 동일합니다. input에 따른 결과가 어떻게 나오는지만 확인하면 됩니다.

이제 가장 중요한 http에 대한 서비스 코드입니다. 우리는 test code를 작성하기 전에 REST API를 호출하는 행위에 대한 정의가 우선 필요합니다.
REST API를 호출하는 것은 다음과 같습니다.

  1. URL에 대한 HTTP request
  2. method에 따른 HTTP request
  3. HTTP response에 대한 결과값에 대한 parsing

결국은 우리가 확인할 것은 위 3가지입니다. 그리고 중점을 줘야지 되는 것을 따지자면 1, 2에 대한 확인입니다. 3에 대한 내용은 REST API의 호출 특성상, API 서버측에서 보내는 결과이기 때문에 그 결과값이 json format인 경우, 우리가 테스트를 해서 확인할 내용이 아닙니다. 우리는 그 결과값을 온전히 받아서 사용하는 client측에서만 생각하면 되기 때문에 1, 2번에 대한 내용만을 테스트한다면 우리가 원하는 test code를 작성할 수 있습니다.

angularJS는 angular-mock을 통해 $httpBackend 객체에 우리가 호출되는 URL, method를 확인할 수 있는 방법을 제공합니다. 일단 다음 상황을 가정해보도록 합니다.

GET /api/as/list

그리고, 이러한 url을 호출하는 API Service를 작성합니다.

function AsService(Restangular, AsServiceValidator) {
  var self = this;
  self.getList = function(status, department, func) {
    if(AsServiceValidator.checkStatus(status) && AsService.checkDepartment(department)) {
      Restangular.all('/api/as/list').get().then(function(jsonResult) {
        if(jsonResult.ok && func) {
          func(jsonResult);
        }
      });
      return true;
    } 
    return false;
  };
}

위 코드는 그 전에 이야기한 validator에 대한 체크 후, Restangular를 이용한 http call을 하고 있습니다. service에 대한 test code를 작성할 때, 반드시 $httpBackend에 대한 expect를 설정해야지 됩니다. 다음은 test code의 일부분입니다.

var httpBackend, service
beforeEach(inject(function($httpBackend, AsService) {
  httpBackend = $httpBackend;
  service = AsService;
}));

위 코드패턴을 이용해서 우리는 테스트의 대상이 되는 service와 $httpBackend를 얻어올 수 있습니다. 이제 우리가 원하는 API를 정상적으로 호출하고 있는지를 확인해보도록 하겠습니다.

it('as list REST API 호출', function() {
  httpBackend.expectGET(/\/api\/as\/list/\W*).respond('{ ok: true, data: null, message: data }');
  service.getList(status, department, function(jsonResult) {
    console.log(jsonResult);
  });
  httpBackend.flush();
});

REST API를 호출하는 service의 test code pattern은 다음과 같습니다.

  1. expectGET/expectPOST/expectDELETE/expectPUT method를 이용해서 request가 전달될 URL을 예상합니다.
  2. service를 호출합니다.
  3. httpBackend.flush() method를 호출합니다.

여기서 주의할점은 httpBackend.flush() 입니다. flush가 호출되게 되면, httpBackend는 httpRequest에 대한 response를 발생시킵니다. 만약에 expect에 정의되지 않은 http request가 발생되게 되면 exception을 발생하게 됩니다. REST API의 response를 명확히 알고 있다면, 그 결과값에 대한 처리 로직도 테스트가 가능합니다.

REST API service에 대한 test code작성방법에 대해서 다시 한번 정의해보도록 하겠습니다.

  1. input에 대한 validator의 분리가 필요 > validator 테스트 코드
  2. $httpBackend.expectXXX method를 이용한 REST API 호출 확인

이 두가지에 중점을 주면 이제 service code 역시 테스트가 가능하게 됩니다.


Posted by Y2K
,
filter의 경우에는 배열에 대한 조건을 처리하고 있기 때문에, 최대한 가벼울 필요가 있는 객체이기도 합니다. 또한, non-HTTP service의 경우에는 값의 계산이나 validation에 대한 처리가 일반적입니다.

filter의 테스트는 다음을 확인하면 됩니다.

input array data의 filtering이 정상적으로 되었는지
> count를 이용하는 것이 일반적입니다.

다음은 간단한 filter code입니다.

angular.module('fmsmobilewebApp').filter('planFilter', function () {
  return function (plans, status) {
    if(status == '' || status == '0') {
      return plans;
    } else {
      var result = [];
      angular.forEach(plans, function(plan) {
        if(plan.statusId == status) {
          result.push(plan);
        }
      });
      return result;
    }
  };
});

위와 같은 filter code의 경우, filter의 input 값을 개발자가 제어를 해서 처리하면 간단히 해결됩니다. 다음과 같은 방법으로요.

describe('Filter: planFilter', function () {
  beforeEach(module('fmsmobilewebApp'));
  var planFilter;
  var plans;

  beforeEach(inject(function ($filter) {
    planFilter = $filter('planFilter');
    plans = [{"section":"정기","sectionId":"1801","type":"일반","mainBody":"대성","classification":"보고관리","priority":"1일이내","planDate":"2014-09-02 16:00","statusId":"0805","name":"A 보고관리 (주 2회)","id":"33913","department":"관리팀","orderDate":"2014-09-11","status":"완료"},{"section":"정기","sectionId":"1801","type":"일반","mainBody":"대성","classification":"보고관리","priority":"1일이내","planDate":"2014-09-05 16:00","statusId":"0805","name":"A 보고관리 (주 2회)","id":"33914","department":"관리팀","orderDate":"2014-09-11","status":"완료"}];
  }));

  it('not filtered (status is empty)', function() {
    var count = plans.length;
    expect(planFilter(plans, '').length).toBe(count);
    expect(planFilter(plans, '0').length).toBe(count);
  });

  it('filtered plans', function() {
    var count = 0;
    var status = '0805';
    angular.forEach(plans, function(plan) {
      if(plan.statusId == status) {
        count++;
      }
    });
    expect(count).toBeGreaterThan(0);
    expect(planFilter(plans, status).length).toBe(count);
  });

});


Posted by Y2K
,
yo의 angular-generator를 이용한 angularJS web application을 테스트 하는 방법을 한번 정리해보도록 하겠습니다.

먼저, 테스트의 대상은 다음과 같습니다.

  • filter, service (non-HTTP)
  • service (HTTP)
  • directive
  • controller

angularJS로 만들어지는 객체들은 모두 test의 대상이 될 수 있습니다. 그렇지만, 저 순서가 조금 중요한 것이 기본적으로 service의 테스트 없이, controller의 테스트는 어렵습니다. 그리고 directive 역시 내부에서 service를 사용하고 있다면, service의 test가 우선이 되어야지 됩니다. 따라서, 위 순서와 비슷하게 dependency에 따른 test의 순서를 결정해보는 것이 좋습니다.

xUnit를 이용한 test와 마찬가지로, unit이라는 범위안에서 dependency가 외부 library(jquery, restangular etc..)등에만 의존이 되어 있는 객체들 부터 테스트를 진행하고, dependency가 내부 객체들에 의존되어 있다면, 그 객체들의 테스트가 우선되어야지 됩니다. 이러한 조건을 먼저 생각하는 것부터 테스트를 시작할 수 있습니다. 그리고, 이 순서는 일반적으로 위에 적어놓은 객체들의 순서로 진행되는 것이 일반적입니다.

환경 설정

karma-jasmine을 먼저 설치해야지 됩니다. 기본으로 설정되어 있는 jasmine test framework를 karma를 통해 실행하기 위한 기본 library입니다.

npm install karam-jasmine

설치후, 사용할 browser에 따른 launcher를 설치해야지 됩니다. 자신의 개발 환경에 맞는 launcher를 설치해주면 됩니다. window, linux, mac에 모두 설치가 가능한 web browser를 선택해주는 것이 개발환경을 구성하는 데 편합니다.

npm install karma-chrome-launcher
npm install karma-firefox-launcher
npm install karma-ie-launcher
npm install karma-safari-launcher

launcher의 경우, karam.conf.js 파일에 사용할 browser의 설정이 필요합니다.

browsers: ['Chrome']

karma로 테스트를 진행하기 위해서는 karma.conf.js 파일을 주의깊게 봐야지 됩니다. 테스트가 초기에 진행되지 않는 모든 이유는 바로 이 파일안에 있습니다. 먼저 확인해봐야지 될 것이 우리가 bower 또는 외부 상용 library들에 의존되는 application을 작성하고 있다는 것을 확인해야지 됩니다. 이는 모든 library들이 load 될 때에, 기본적인 library들이 먼저 loading 되어야지 되는 것을 의미합니다. 기본적인 library들을 loading하는 것을 karma에서는 files로 정의하고 있습니다. 또한, files에는 test의 target이 되는 library들과 unit test code역시 정의되어 있어야지 됩니다. 따라서, files는 다음과 같은 구성을 갖게 됩니다.

    files: [
      // bower components
      'app/bower_components/jquery/dist/jquery.js',
      'app/bower_components/angular/angular.js',
      'app/bower_components/angular-mocks/angular-mocks.js',
      'app/bower_components/angular-resource/angular-resource.js',
      'app/bower_components/angular-cookies/angular-cookies.js',
      'app/bower_components/angular-sanitize/angular-sanitize.js',
      'app/bower_components/angular-route/angular-route.js',
      'app/bower_components/angular-touch/angular-touch.min.js',
      'app/bower_components/lodash/dist/lodash.min.js',
      'app/bower_components/mobile-angular-ui/dist/js/mobile-angular-ui.min.js',
      'app/bower_components/restangular/dist/restangular.min.js',
      'app/bower_components/angular-local-storage/angular-local-storage.min.js',
      // 3rd party library
      'app/library/kendo/js/kendo.all.min.js',
      // Test target
      'app/scripts/*.js',
      'app/scripts/**/*.js',
      // Test code
      'test/mock/**/*.js',
      'test/spec/**/*.js'
    ],

특히 jquery의 경우에는 사용하고 있는 경우, 최상단에 넣어주는 것이 좋습니다. 많은 library들이 jquery에 의존적이며, angularJS의 경우에는 내장된 jqLite가 jquery가 있는 경우 jquery를 사용하도록 되어 있기 때문입니다.

이제 karma를 구동할 grunt에 대한 설정을 해보도록 하겠습니다. yo를 이용한 web application을 구성하는 경우, 다음 3가지의 application이 모든 동작을 제어하게 됩니다.

  • yeoman : code에 대한 scafolding 제공, code의 기본적인 구조 제공. template을 이용한 code generater라고 이해하면 쉽습니다.
  • bower : gradle, maven과 같은 library dependency 관리 툴입니다. 이제 jquery를 얻기 위해서 home page에 들어가서 다운 받을 필요가 없습니다.
  • grunt : build tool입니다. test의 진행 또는 webserver의 시작등을 모두 grunt를 통해서 진행합니다.

grunt는 Gruntfile.js 파일을 기반으로 동작합니다. 여기서 karma에 관련된 설정만 처리하면 됩니다. 큰 변경은 필요없고, 개발과 test를 동시에 자동으로 처리하도록 설정하면 개발이 매우 편합니다.

    // Test settings
    karma: {
      unit: {
        configFile: 'karma.conf.js',
        singleRun: false,
        authWatch: true
      }
    }
  • singleRun(default : true) : test가 한번만 진행됩니다. 테스트를 연속적으로 계속 진행할 수 있도록 true로 수정해주면 좋습니다.
  • authWatch(default : false) : 파일의 변경이 있는 경우, test를 다시 진행합니다. 충분히 빠릅니다. 약 90여개의 test code의 경우, 1sec내로 테스트를 진행할 수 있습니다.

이제 테스트를 진행할 수 있는 환경 구성이 모두 마쳐졌습니다. 먼저 jasmine에 대한 소개를 간략하게 하고, 각 객체의 test를 하는 방법에 대하여 알아보도록 하겠습니다.

jasmine

jasmine은 javascript의 test framework로서, xUnit의 역활을 맡게 됩니다.
jasmine의 소개는 다음 url에서 확인해보실 수 있습니다. http://jasmine.github.io/2.0/introduction.html

기본적으로 jasmine은 suites를 기반으로 동작합니다. suites는 descirbe로 선언이 되며, 이 test code가 어떤 test code인지를 서술하는 기능을 갖습니다.

describe('sample test code suit', function() {

});

xUnit에서 사용되는 @Test/[Test]는 it으로 정의됩니다.

describe('sample test code suit', function() {
  it('sample test code unit', function() {
      // Sample Test code
  });
});

xUnit의 @SetUp/[SetUp]은 beforeEach로 정의 됩니다.

describe('sample test code suit', function() {
  beforeEach('pre-run codes each test codes', function() {
      // SetUp code
  });
  it('sample test code unit', function() {
      // Sample Test code
  });
});

xUnit의 @TearDown/[TearDown]은 afterEach로 정의됩니다.

describe('sample test code suit', function() {
  beforeEach('pre-run codes each test codes', function() {
      // SetUp code
  });
  it('sample test code unit', function() {
      // Sample Test code
  });
  afterEach('after-run codes each test codes', function() {

  });
});

beforeEach, afterEach의 경우 여러개가 있어도 상관 없으며, 여러 코드 블럭이 있는 경우, 위에서부터 아래로 code가 실행되게 됩니다.

기본적으로 xUnit에서 사용되는 Test code의 개념을 그대로 들고 왔기 때문에, 사용하기가 매우 편한것을 알 수 있습니다. jasmine은 이제 test code의 기계적인 확인을 위한 여러 matcher 들을 제공합니다. 다음은 matcher들의 종류입니다.

matcher description
expect(target).toBe(value) value와 같은지를 확인합니다.
expect(target).toEqual(value) value와 같은지, 그리고 type이 동일한지를 비교합니다.
expect(target).toBeGreaterThan(value) value보다 값이 큰지를 비교합니다.
expect(target).toBeNull() target이 null인지 확인합니다.
expect(target).toBeDefined() target이 define되어 있는지 확인합니다.
expect(target).toBeTruthly() target이 true인지 확인합니다. 이는 if(target) 의 결과와 동일합니다.
expect(target).toBeFalsy() target이 false인지 확인합니다. 이는 if(!target) 의 결과와 동일합니다.
모든 matcher는 not을 가질 수 있습니다.
> expect(target).not.toBe(value);
> expect(target).not.toBeNull();

jasmine은 method에 대한 call 확인을 지원합니다. 하나의 method가 내부의 특정 method를 호출을 했는지, 호출의 input parameters들을 확인할 수 있습니다. 다음은 예시코드입니다.

  var obj = {
    method1 : function() {
      console.info('call method1');
      this.method2('test value');
    },
    method2 : function(value) {
      console.info(value);
    }
  };

  describe('obj test', function() {
    it('obj method2 called Test', function() {
      spyOn(obj, 'method2');
      obj.method1();
      expect(obj.method2).toHaveBeenCalled();
      expect(obj.method2).toHaveBeenCalledWith('test value');
    });
  });

spyOn 을 이용해서, 감시할 대상을 선정하고, method의 호출을 확인할 수 있습니다. spyOn을 이용한 method의 호출에 대한 matcher는 다음과 같습니다.

matcher description
expect(obj.method).toHaveBeenCalled() method가 호출이 되었는지 확인합니다.
expect(obj.method).toHaveBeenCalledWith(“args”) method가 특정 argument들이 전달되었는지 확인합니다.

Posted by Y2K
,