블로그 이미지
Peter Note
Web & LLM FullStacker, Application Architecter, KnowHow Dispenser and Bike Rider

Publication

Category

Recent Post

2013. 10. 23. 17:48 Testing, TDD/Test First

AngularJS를 위한 Test 수행 방법을 생각해 보고, 테스트 전략에 대해서 다른 개발자는 어떻게 하고 있는지 알아보자 


  



1. Angular Testing 에 대한 고찰

 1-1. 스토리 보드 만들기 

  - 프로젝트 진행이 Agile Scrum 이라면 Story를 먼저 도출한다 

  - Story가 도출되었다면 스토리안에 Task를 나눈다 그리고 Task 별로 Validation(검증) 및 Processing(처리)해야할 것을 명세한다

  - 명세는 스토리카드안에 간단히 적는다. 


 1-2. UX&UI 디자인

  - 스토리에 맞는 화면의 목업(Mockup or WireFrame)을 그린다. Balsamiq같은 목업툴을 이용한다 

  - 화면 목업이 스토리에 부합되는지 확인 되면 스토리 개발 우선순위를 결정한다

  - 결정된 화면의 HTML을 Bootstrap 또는 BootFlat을 이용하여 코드를 만든다. 저작툴이 Bootply를 이용해도 된다 


 1-3. TDD 수행하기 개발

  - AngularJS 기반의 개발시 다음과 같이 진행을 한다 (AngularWay 참조)

    + View  === AngularJS의 Directive가 포함된 HTML이다 

    + Model === $scope를 통하여 Controller에서 Two way binding을 자동 수행한다 

    + View와 Controller를 통하여 표현과 행위를 분리한다 (SoC)

    + AngularJS 애플리케이션 접근법

      Step 1) Model을 먼저 생각하고 Service를 만든다

      Step 2) Model이 표현될 View에 대해 생각해 보고 template을 만들고, 필요하면 자동 모델 바인딩되는 Directive도 만든다.

      Step 3) 각 View 를 Controller에 연결한다 (ng-view and routing, ng-controller)


  - E2E Testing

    + AngularJS의 Config의 Routing 에 대해 E2E Test 수행 

    + Model을 표현하는 template에 대해 E2E Test 수행 

    + Directives를 HTML에 코딩하였다면 E2E Test 수행 

    + Filter가 HTML에 표현되는 것이라면 E2E Test 수행

    (Protractor 또는 Angular Test Scenario Runner 사용)

  - Unit Testing

    + Model을 서버 또는 Controller로 부터 받으면 Service/Factory에 대하여 Validation과 XHR등 스팩에 대한 Unit Test 수행

    + Model을 가공 핸들링하여 View와 양방향 연동하는 Controller에 대한 Unit Test 수행

    + Directives/Filter 의 내부 로직에 대한 Unit Test 수행 

    (Mocha 기반의 Chai와 같은 expectation, assertion 사용)


 1-4. 개발 툴체인

  - Yeoman 을 통하여 AngularJS 스케폴딩 코딩을 한다 (참조)

  - 1-3의 E2E 와 Unit Testing을 위하여 AngularJS의 Karma Test Framework안에서 사용하면 된다. 단, Protractor사용시 예외



2. 테스트 전략예 동영상 

  - AngularJS에 대한 Test 전략에 대한 동영상을 보자 

    + testem을 통해 Unit Test를 수행

    + protractor를 통해 E2E Test를 수행

    + 제품 통합 테스트 수행을 위하여 Yeoman과 유사한 Lineman을 사용

    + Jasmine-given을 사용하여 Given-When-Then의 CoffeeScript 방식의 재미있는 테스팅도 소개함

     


  - 새롭게 나온 E2E Test Framework인 Protractor for angularJS 

    + Angular팀에서 새롭게 소개된 Protractor 느낌상 Karma E2E 보다는 더 간단하고 직관적인듯 하다.

     



<참조>

  - End-to-End Testing with AngularJS

  - Front javascript testing framework

posted by Peter Note
2013. 10. 21. 19:01 Testing, TDD/Test First

Karma 테스트 프레임워크를 통하여 AngularJS기반 애플리케이션을 어떻게 테스트 하는지 알아보자 



AngularJS의 두가지 테스트 타입 

  - Unit Testing : 작고 격리된 코드 유닛의 동작에 대한 검증 테스트 

  - E2E Testing : 애플리케이션 전영역에 대한 테스트. E2E 테스터는 로봇처럼 브라우져를 실행하여 페이지를 검증해 준다 

  - AngularJS에서 이야기하는 E2E테스트 시나리오 API : Angular Scenario Runner 

    + describe 

    + beforeEach

    + afterEach

    + it

describe('Buzz Client', function() {

 it('should filter results', function() {

   input('user').enter('jacksparrow');

   element(':button').click();

   expect(repeater('ul li').count()).toEqual(10);

   input('filterText').enter('Bees');

   expect(repeater('ul li').count()).toEqual(1);

 });

});


  - Testing의 유형을 나누어 본다 : Unit, Midway, E2E

    + Unit Testing

      코드레벨 테스트

      격리된 테스트

      Mock & Stubbing 요구, 빠름

    + Midway Testing

      애플리케이션/코드레벨 테스트

      애플리케이션의 모든 부분 접근 가능

      다른 애플리케이션 코드와 상호작용

      뷰(html) 내부의 테스트는 불가능능

      빠름, 단, XHR일 경우 느릴 수 있음 

    + E2E Testing

      웹레벨 테스트

      웹서버가 필요

      완벽한 통합 테스트 



샘플코드 설치 및 수행

  - 데모 페이지

  - 소스 : GitHub Repository

  - 설치 (참조)

$ git clone git://github.com/yearofmoo-articles/AngularJS-Testing-Article.git

Cloning into 'AngularJS-Testing-Article'...

remote: Counting objects: 536, done.

remote: Compressing objects: 100% (368/368), done.

remote: Total 536 (delta 130), reused 516 (delta 117)

Receiving objects: 100% (536/536), 1.28 MiB | 390.00 KiB/s, done.

Resolving deltas: 100% (130/130), done.


$ cd AngularJS-Testing-Article/ && npm install


// 만일 제대로 npm install시 에러가 발생하면 package.json의 버전을 바꾼다

$ vi package.json

   "grunt-karma": "latest",

    "karma": "latest",

  - 수행 : http://localhost:8000 으로 호출한다 

$ grunt server

Running "connect:server" (connect) task

Starting connect web server on localhost:8000.

Waiting forever...

  - 디렉토리 구조 

    + test 밑에 3가지의 karma 환경파일이 존재한다

    + grunt test 명령으로 test 프로그램을 수행할 수 있다 - grunt test, grunt karma:unit, grunt karma:midway, grunt test:e2e (참조)

       * 테스트 안될 경우 주의

        1) bower_components를 components 폴더로 명칭 변경

        2) ngMidwayTester 못 찾으면 : comoponents/ngMidwayTest/src 에서 src를 Source 폴더로 명칭 변경  

    + 각 파트별 수행 테스트 파일은 unit, midway, e2e 폴더로 나뉜다 

    

  - Karma안에서 사용한 Test Frameworks은 test/ 폴더 밑으로 karma-e2e/midway/unit/shared.conf.js 로 설정되어 있다 

    + Mocha.js : Unit Test

    + Chai.js : matchers and assertions

    + Jasmine.js : End-To-End Test(E2E) Framework으로 Angular Scenario Runner에서 사용


  * Midway Plugin에서 에러가 발생한다. 해결하면 500원



Mocha, Chai 그리고 Angular Scenario Runner

  - Unit 과 Midway를 테스트에는 테스트 스팩은 Mocha(모카)를 이용하고 Matcher/Assertion으로 Chai를 사용한다  

  - E2E 테스트시에는 Mocah, Chai를 사용할 수 없었다. 별도의 E2E 수행 문서를 제공한다

  - 테스트 시에 AngularJS는 XHR 요청도 Interceptors를 통해서 가로챌 수 있다. 

     그외 route, controller, service, directive까지도 가로채서 테스트 코드를 넣을 수 있다. 

  - XHR 가로채기의 비용이 크면 angular-mock.js를 통하여 Mock을 사용할 수도 있다 



1. Testing Module

  - AngularJS에서 모듈은 directives, controllers, templates, services 그리고 resources 생성을 위한 컨테이너 오브젝트이다

  - 따라서 테스트에 최초로 할 것이 해당 모듈이 있는지 체크하는 것이다 

  - Midway 테스트에서 수행한다 

  - midway/appSpec.js

//
// test/midway/appSpec.js
//
describe("Midway: Testing Modules", function() {
  describe("App Module:", function() {

    var module;
    before(function() {
      module = angular.module("App");
    });

    it("should be registered", function() {
      expect(module).not.to.equal(null);
    });

    // App이 의존하는 모듈들이 있는지 검증 
    describe("Dependencies:", function() {

      var deps;
      var hasModule = function(m) {
        return deps.indexOf(m) >= 0;
      };
      before(function() {
        deps = module.value('appName').requires;
      });

      //you can also test the module's dependencies
      it("should have App.Controllers as a dependency", function() {
        expect(hasModule('App.Controllers')).to.equal(true);
      });

      it("should have App.Directives as a dependency", function() {
        expect(hasModule('App.Directives')).to.equal(true);
      });

      it("should have App.Filters as a dependency", function() {
        expect(hasModule('App.Filters')).to.equal(true);
      });

      it("should have App.Routes as a dependency", function() {
        expect(hasModule('App.Routes')).to.equal(true);
      });

      it("should have App.Services as a dependency", function() {
        expect(hasModule('App.Services')).to.equal(true);
      });
    });
  }); 

});



2. Testing Routes

  - 애플리케이션의 페이지 라우팅이 제대로 되는지 테스트 한다 

  - Midway, E2E 테스트에서 수행한다 

  - Midway Testing (Midway Testser Plugin)

//
// test/midway/routesSpec.js
//
describe("Testing Routes", function() {

  var test;

  before(function(done) {
    test = new ngMidwayTester();
    test.register('App', done);
  });

  it("should have a videos_path", function() {
    expect(ROUTER.routeDefined('videos_path')).to.equal(true);
    var url = ROUTER.routePath('videos_path');
    expect(url).to.equal('/videos');
  });

  it("the videos_path should goto the VideosCtrl controller", function() {
    var route = ROUTER.getRoute('videos_path');
    route.params.controller.should.equal('VideosCtrl');
  });

  it("the home_path should be the same as the videos_path", function() {
    expect(ROUTER.routeDefined('home_path')).to.equal(true);
    var url1 = ROUTER.routePath('home_path');
    var url2 = ROUTER.routePath('videos_path');
    expect(url1).to.equal(url2);
  });
 

});

  - E2E Testing 

// test/e2e/routesSpec.js
//
describe("E2E: Testing Routes", function() {

  beforeEach(function() {
    browser().navigateTo('/');
  });

  it('should jump to the /videos path when / is accessed', function() {
    browser().navigateTo('#/');
    expect(browser().location().path()).toBe("/videos");
  });

  it('should have a working /videos route', function() {
    browser().navigateTo('#/videos');
    expect(browser().location().path()).toBe("/videos");
  });

  it('should have a working /wathced-videos route', function() {
    browser().navigateTo('#/watched-videos');
    expect(browser().location().path()).toBe("/watched-videos");
  });

  it('should have a working /videos/ID route', function() {
    browser().navigateTo('#/videos/10');
    expect(browser().location().path()).toBe("/videos/10");
  });

});



3. Testing Controllers

  - $scope를 통하여 template 페이지와 데이터 바인딩 되는 테스트 

  - Unit Testing 

// test/unit/controllers/controllersSpec.js
//
describe("Unit: Testing Controllers", function() {

  beforeEach(angular.mock.module('App'));

  it('should have a VideosCtrl controller', function() {
    // controller 모듈이 있는지 검증
    expect(App.VideosCtrl).not.to.equal(null);
  });

  it('should have a VideoCtrl controller', function() {
    expect(App.VideoCtrl).not.to.equal(null);
  });

  it('should have a WatchedVideosCtrl controller', function() {
    expect(App.WatchedVideosCtrl).not.to.equal(null);
  });

  // $httpBackend Mock 객체를 통해 단위 테스트 검증
  it('should have a properly working VideosCtrl controller', 
    inject(function($rootScope, $controller, $httpBackend) {
    var searchTestAtr = 'cars';
    var response = $httpBackend.expectJSONP('https://gdata.youtube.com/feeds/api/videos?q='
                     + searchTestAtr + '&v=2&alt=json&callback=JSON_CALLBACK');
    response.respond(null);

    var $scope = $rootScope.$new();
    var ctrl = $controller('VideosCtrl', {
      $scope : $scope,
      $routeParams : {
        q : searchTestAtr
      }
    });
  }));

  it('should have a properly working VideoCtrl controller', 
       inject(function($rootScope, $controller, $httpBackend) {
    var searchID = 'cars';
    var response = $httpBackend.expectJSONP('https://gdata.youtube.com/feeds/api/videos/' 
                     + searchID + '?v=2&alt=json&callback=JSON_CALLBACK');
    response.respond(null);

    var $scope = $rootScope.$new();
    var ctrl = $controller('VideoCtrl', {
      $scope : $scope,
      $routeParams : {
        id : searchID
      }
    });
  }));

  it('should have a properly working WatchedVideosCtrl controller', 
         inject(function($rootScope, $controller, $httpBackend) {
    var $scope = $rootScope.$new();

    //we're stubbing the onReady event
    $scope.onReady = function() { };
    var ctrl = $controller('WatchedVideosCtrl', {
      $scope : $scope
    });
  }));
 

});

  - Midway Testing

// test/midway/controllers/controllersSpec.js

describe("Midway: Testing Controllers", function() {

  var test, onChange;
  // Async Test로 done 객체 파라미터 전달 
  before(function(done) {
    ngMidwayTester.register('App', function(instance) {
      test = instance;
      done();
    });
  });

  // 라투트통하여 페이지 변경 성공 이벤트 발생하면 onChange() 호출
  before(function() {
    test.$rootScope.$on('$routeChangeSuccess', function() {
      if(onChange) onChange(); 
    });
  });

  beforeEach(function(done) {
    test.reset(done);
  });

  it('should load the VideosCtrl controller properly when /videos route is accessed', function() {
    onChange = function() {
      test.path().should.eq('/videos');
      var current = test.route().current;
      var controller = current.controller;
      var scope = current.scope;
      expect(controller).to.equal('VideosCtrl');
    };
    test.path('/videos'); // /videos 호출되면 자동으로 onChange() 호출되어 검증 
  });

  it('should load the WatchedVideosCtrl controller properly when /watched-videos route is accessed', function(done) {
    onChange = function() {
      test.path().should.eq('/watched-videos');
      var current = test.route().current;
      var controller = current.controller;
      var params = current.params;
      var scope = current.scope;

      expect(controller).to.equal('WatchedVideosCtrl');
      done();
    };
    test.path('/watched-videos');
  });

});

  - E2E Testing

// test/e2e/controllers/controllersSpec.js
//
describe("E2E: Testing Controllers", function() {

  // 첫 페이지 있는지 검증 
  beforeEach(function() {
    browser().navigateTo('/');
  });

  // videos의 html 화면에서 DIV id="ng-view"의 html 내역 안에 data-app-youtube-listings이 있는지 검증   
  it('should have a working videos page controller that applies the videos to the scope', function() {
    browser().navigateTo('#/');
    expect(browser().location().path()).toBe("/videos");
    expect(element('#ng-view').html()).toContain('data-app-youtube-listings');
  });

  it('should have a working video page controller that applies the video to the scope', function() {
    browser().navigateTo('#/videos/WuiHuZq_cg4');
    expect(browser().location().path()).toBe("/videos/WuiHuZq_cg4");
    expect(element('#ng-view').html()).toContain('app-youtube-embed');
  }); 

}); 



4. Testing Services/Factories 

  - 서비스는 테스트가 가장 쉬운 코들 블럭이다 

  - Service와 Factory에 대해서 테스트 하는 방법

  - Unit Testing

// test/unit/services/servicesSpec.js
//
describe("Unit: Testing Controllers", function() {

  beforeEach(angular.mock.module('App'));

  it('should contain an $appStorage service', inject(function($appStorage) {
    expect($appStorage).not.to.equal(null);
  }));

  // 서비스 존재 유무 검증 
  it('should contain an $appYoutubeSearcher service', inject(function($appYoutubeSearcher) {
    expect($appYoutubeSearcher).not.to.equal(null);
  }));

  it('should have a working $appYoutubeSearcher service', inject(['$appYoutubeSearcher',function($yt) {
    expect($yt.prefixKey).not.to.equal(null);
    expect($yt.resize).not.to.equal(null);
    expect($yt.prepareImage).not.to.equal(null);
    expect($yt.getWatchedVideos).not.to.equal(null);
  }]));

  // $appYoutubeSearcher Factory 검증 
  it('should have a working service that resizes dimensions', inject(['$appYoutubeSearcher',function($yt) {
    var w = 100;
    var h = 100;
    var mw = 50;
    var mh = 50;
    var sizes = $yt.resize(w,h,mw,mh);
    expect(sizes.length).to.equal(2);
    expect(sizes[0]).to.equal(50);
    expect(sizes[1]).to.equal(50);
  }]));

  // $appStorage Factory 검증 
  it('should store and save data properly', inject(['$appStorage',function($storage) {
    var key = 'key', value = 'value';
    $storage.enableCaching();
    $storage.put(key, value);
    expect($storage.isPresent(key)).to.equal(true);
    expect($storage.get(key)).to.equal(value);

    $storage.erase(key);
    expect($storage.isPresent(key)).to.equal(false);

    $storage.put(key, value);
    $storage.flush();
    expect($storage.isPresent(key)).to.equal(false);
  }]));
 

});

  - Midway Testing 

// test/midway/services/servicesSpec.js
//
describe("Midway: Testing Services", function() {

  var test, onChange, $injector;

  before(function(done) {
    ngMidwayTester.register('App', function(instance) {
      test = instance;
      done();
    });
  });

  // 화면 변경이 있을 경우 onChange() 호출 
  before(function() {
    test.$rootScope.$on('$routeChangeSuccess', function() {
      if(onChange) onChange(); 
    });
  });

  before(function() {
    $injector = test.injector();
  });

  beforeEach(function() {
    //test.reset();
  });

  // $appYoutubeSearcher 를 $injector로 부터 가져옴. findeVideo 호출함 
  it('should perform a JSONP operation to youtube and fetch data', function(done) {
    var $yt = $injector.get('$appYoutubeSearcher');
    expect($yt).not.to.equal(null);

    //this is the first video ever uploaded on youtube
    //so I doubt it will be removed anytime soon
    //and should be a good testing item
    var youtubeID = 'jNQXAC9IVRw';

    $yt.findVideo(youtubeID, false,
      function(q, data) {
        expect(data).not.to.equal(null);
        expect(data.id).to.equal(youtubeID);
        done();
      }
    );
  });
 

});



5. Testing Directives

  - AngularJS입장에서 HTML 코드안에서 컴포넌트 역할이다 

    HTML상에 반복되며 격리될 수 있는 것을 Directive로 만든다. 따라서 HTML 코드 내역은 최소화 되고 불필요한 반복을 줄일 수 있다.

  - Directive가 $scope와 DOM을 가지고 어떻게 작동할지 테스트 해야 한다 

  - XHR을 호출할 수도 있다. 따라서 Unit, Midway, E2E 전부분의 테스트를 수행한다 

  - Unit Testing 

// test/unit/directives/directivesSpec.js
//
describe("Unit: Testing Directives", function() {

  var $compile, $rootScope;

  beforeEach(angular.mock.module('App'));

  // 
  beforeEach(inject(
    ['$compile','$rootScope', function($c, $r) {
      $compile = $c;
      $rootScope = $r;
    }]
  ));

  // app-welcome Directive안에 Welcome 글자와 매치하는지 검증
  it("should display the welcome text properly", function() {
    var element = $compile('<div data-app-welcome>User</div>')($rootScope);
    expect(element.html()).to.match(/Welcome/i);
  })

});

  - Midway Testing

// test/midway/directives/directivesSpec.js
//
describe("Midway: Testing Directives", function() {

  var test, $injector;

  // $injector 얻어오기 
  before(function(done) {
    ngMidwayTester.register('App', function(instance) {
      test = instance;
      done();
    });
  });

  before(function() {
    $injector = test.$injector;
  });

  // $appYoutubeSearcher 통하여 응답을 받은후 app-youtube-listings Directive를 검증한다. XHR호출이므로 setTimeout 값으로 1초를 준다 
  it("should properly create the youtube listings with the directive in mind", function(done) {
    var $youtube = $injector.get('$appYoutubeSearcher');

    var html = '';
    html += '<div data-app-youtube-listings id="app-youtube-listings">';
    html += ' <div data-ng-include="\'templates/partials/youtube_listing_tpl.html\'" data-ng-repeat="video in videos"></div>';
    html += '</div>';

    var $scope = test.scope();
    var element = angular.element(html);

    $youtube.query('latest', false, function(q, videos) {
      $scope.videos = videos;

      test.directive(element, $scope, function(element) {
        setTimeout(function() {
          var klass = (element.attr('class') || '').toString();
          var hasClass = /app-youtube-listings/.exec(klass);
          expect(hasClass.length).to.equal(1);

          var kids = element.children('.app-youtube-listing');
          expect(kids.length > 0).to.equal(true);
          done();
        },1000);
      });
    });
  });

});

  - E2E Testing

// test/e2e/directives/directivesSpec.js
//
describe("E2E: Testing Directives", function() {

  beforeEach(function() {
    browser().navigateTo('/');
  });

  // 화면을 이동하였을 때 Directive가 표현하는 HTML 내역이 있는지 검증
  it('should have a working welcome directive apply it\'s logic to the page', function() {
    browser().navigateTo('#/videos');
    expect(browser().location().path()).toBe("/videos");
    expect(element('#app-welcome-text').html()).toContain('Welcome');
  });

  it('should have a working youtube listing directive that goes to the right page when clicked', function() {
    browser().navigateTo('#/videos');
    element('.app-youtube-listing').click();
    expect(browser().location().path()).toMatch(/\/videos\/.+/);
  });

});




6. Testing Templates, Partials & Views 

  - 격리된 HTML 코드이다 

  - 앵귤러에서는 ngView 또는 ngInlcude 통하여 렌더링된다 

  - 뷰는 $templateCache 서비스 통해서 캐싱되어 제공된다. 

    테스트시 templateUrl을 주면 캐싱된 mock template을 얻어와 사용할 수 있다 

  - Midway Testing

// test/midway/templates/templatesSpec.js
//
describe("Midway: Testing Requests", function() {

  var test, onChange;
  var $location, $injector, $params;

  // url path 변경시 onChange() 호출
  before(function(done) {
    ngMidwayTester.register('App', function(instance) {
      test = instance;
      test.$rootScope.$on('$routeChangeSuccess', function() {
        if(onChange) onChange(); 
      });
      done();
    });
  });

  before(function() {
    $injector = test.$injector;
    $location = test.$location;
    $params   = test.$routeParams;
  });

  beforeEach(function() {
    onChange = null;
  });

  // templateUrl을 test.path('XXX') 호출후 template 명칭이 맞는지 검증
  it("should load the template for the videos page properly", function(done) {
    onChange = function() {
      setTimeout(function() {
        var current = test.route().current;
        var controller = current.controller;
        var template = current.templateUrl;
        expect(template).to.equal('templates/views/videos/index_tpl.html');
        onChange = null
        done();
      },1000);
    };
    test.path('/videos?123');
  });
 

});

  - E2E Testing

// test/e2e/templates/templatesSpec.js
//
describe("E2E: Testing Templates", function() {

  beforeEach(function() {
    browser().navigateTo('/');
  });

  // 각 templateUrl 이동시 화면 내역을 검증
  it('should redirect and setup the videos page template on root', function() {
    browser().navigateTo('#/');
    expect(element('#ng-view').html()).toContain('youtube_listing');
  });

  it('should load the watched videos template into view', function() {
    browser().navigateTo('#/watched-videos');
    expect(element('#ng-view').html()).toContain('youtube_listing');
  });

  it('should load the watched video template into view', function() {
    browser().navigateTo('#/videos/123');
    expect(element('#ng-view').html()).toContain('profile');
  });

  it('should redirect back to the index page if anything fails', function() {
    browser().navigateTo('#/something/else');
    expect(element('#ng-view').html()).toContain('youtube_listing');
  });
 

});



7. Testing Filters

  - filter 테스트시에는 $injector 서비스가 필요하고, $injector로 부터 $filter를 얻어온다 

  - Unit Testing

// test/unit/filters/filtersSpec.js
//
describe("Unit: Testing Filters", function() {

  beforeEach(angular.mock.module('App'));

  it('should have a range filter', inject(function($filter) {
    expect($filter('range')).not.to.equal(null);
  }));

  // $filter 서비스를 받아서 range 필터를 얻는다 
  it('should have a range filter that produces an array of numbers', inject(function($filter) {
    var range = $filter('range')([], 5);
    expect(range.length).to.equal(5);
    expect(range[0]).to.equal(0);
    expect(range[1]).to.equal(1);
    expect(range[2]).to.equal(2);
    expect(range[3]).to.equal(3);
    expect(range[4]).to.equal(4);
  }));

  it('should return null when nothing is set', inject(function($filter) {
    var range = $filter('range')();
    expect(range).to.equal(null);
  }));

  // range filter의 input에 대한 검증
  it('should return the input when no number is set', inject(function($filter) {
    var range, input = [1];
    range = $filter('range')(input);
    expect(range).to.equal(input);

    range = $filter('range')(input, 0);
    expect(range).to.equal(input);

    range = $filter('range')(input, -1);
    expect(range).to.equal(input);

    range = $filter('range')(input, 'Abc');
    expect(range).to.equal(input);
  }));
 

});

  - Mideway Testing

// test/midway/filters/filtersSpec.js

//
describe("Midway: Testing Filters", function() {

  var test, onChange, $filter;

  // 최초 한번 미리 $filter 서비스를 얻어온다 
  before(function(done) {
    ngMidwayTester.register('App', function(instance) {
      test = instance;
      test.$rootScope.$on('$routeChangeSuccess', function() {
        if(onChange) onChange(); 
      });

      $filter = test.filter();

      done();
    });
  });

  beforeEach(function() {
    test.reset();
  });

  it('should have a working range filter', function() {
    expect($filter('range')).not.to.equal(null);
  });

  // html 템플릿 DOM을 만들어서 append 하고, Directives에 사용한 range에 대해서 검증
  it('should have a working filter that updates the DOM', function(done) {
    var id = 'temp-filter-test-element';
    var html = '<div id="' + id + '"><div class="repeated" ng-repeat="n in [] | range:10">...</div></div>';
    var element = angular.element(html);
    angular.element(document.body).append(html);

    test.directive(element, test.scope(), function(element) {
      var elm = element[0];
      setTimeout(function() {
        var kids = elm.getElementsByTagName('div');
        expect(kids.length).to.equal(10);
        done();
      },1000);
    });
  });

});

  - E2E Testing 

// test/e2e/filters/filtersSpec.js

//
describe("E2E: Testing Filters", function() {

  beforeEach(function() {
    browser().navigateTo('/');
  });

  // range 필터가 사용된 화면으로 이동하였을 경우 화면이 정상적으로 표시 되는지 검증
  it('should have a filter that expands the stars properly', function() {
    browser().navigateTo('#/videos/WuiHuZq_cg4');
    expect(repeater('#app-youtube-stars > .app-youtube-star').count()).toBeGreaterThan(0);
  });

});



<참조>

  - 원문 : Full Spectrum Test in AngularJS 

  - Javascript 테스트를 어렵게 하는 6가지

  - Service Test 전략 동영상

    


  - AngularJS를 위한 새로운 E2E Test Framework "Protractor"

  - Protractor로 E2E 테스트하기 : 기존 Karma E2E 보다 쉬워진 느낌이다. 30분 부터 보시라

    


posted by Peter Note
2013. 10. 20. 21:12 Testing, TDD/Test First

AngularJS 기반하에 TDD를 수행하거나 테스트 코드를 작성할 때 적합한 툴과 개념에 대해 이해를 하자



1. Unit Testing

  - 단위 기능 테스트 

  - 추천 단위 테스트 툴

    + Mocha : 단순하며 유연한 테스트 프레임워크 (추천)

    + Jasmine : Behavior-Driven Development Framework for testing Javascript (추천)

    + QUnit : jQuery에서 사용

  - 단위 테스트 만들기 

    + 사용자 스토리 기반으로 만들어 보자 

       "사용자로써 나의 앱에 로그인을 하면 대시보드 페이지를 본다"

    + Story -> Features -> Units 로 구분을 한다 

       "로그인 폼"을 하나의 기능으로 선택한다

       하나의 스토리는 여러 기능의 합집합이며, 각 기능의 정상작동 검증(Verification)을 거쳐서 하나의 스토리는 완성된다 

    + 로그인 폼에 대한 Spec을 만든다 (BDD)

describe('user login form', function() {


    // critical : 기능의 검증

    it('ensure invalid email addresses are caught', function() {});

    it('ensure valid email addresses pass validation', function() {});

    it('ensure submitting form changes path', function() { });


    // nice-to-haves

    it('ensure client-side helper shown for empty fields', function() { });

    it('ensure hitting enter on password field submits form', function() { });


});

   

  - 위의 테스트 Spec을 AngularJS로 단위 테스트 만들기 

    + 파일 : angular.js, angular-mocks.js, app.js(모듈명-App), loginController.js(LoginCtrl),  loginService.js(LoginService)

    + beforeEach에서 angular.mock.module 통해 모듈을 셋업한다 

       beforeEach에서 angular.mock.inject 통해 controller에서 $scope 셋업한다 (참조) 

    + it 에서 inject 통하여 service를 셋업한다 (참조)

describe("Unit Testing Examples", function() {


  beforeEach(angular.mock.module('App')); 


  it('should have a LoginCtrl controller', function() {

    expect(App.LoginCtrl).toBeDefined();

  });


  it('should have a working LoginService service', inject(['LoginService',

    function(LoginService) {

      expect(LoginService.isValidEmail).not.to.equal(null);


      // test cases - testing for success

      // 검증을 위한 테스트 데이터 

      var validEmails = [

        'test@test.com',

        'test@test.co.uk',

        'test734ltylytkliytkryety9ef@jb-fe.com'

      ];


      // test cases - testing for failure

      var invalidEmails = [

        'test@testcom',

        'test@ test.co.uk',

        'ghgf@fe.com.co.',

        'tes@t@test.com',

        ''

      ];


      // you can loop through arrays of test cases like this

      for (var i in validEmails) {

        var valid = LoginService.isValidEmail(validEmails[i]);

        expect(valid).toBeTruthy();

      }

      for (var i in invalidEmails) {

        var valid = LoginService.isValidEmail(invalidEmails[i]);

        expect(valid).toBeFalsy();

      }


    }]) // end inject 

  ); // end it 

}); // end describe



2. Integration Testing 

  - 통합 테스트는 end-to-end 테스트(E2E)이고, 수행순서대로 차례로 수행해 보는 것이다. 

     그리고 애플리케이션과 UI의 상태를 검증한다. 심지어 Visual적인 부분에 대한 검증도 가능하다 

  - 추천 도구 

    + Karma : AngularJS에서 공식사용 (추천)

    + CasperJS : headless browser로 사용 

    + PhantomJS : headles brower

  - 통합 테스트 만들기 

    + "사용자로써 나의 앱에 로그인하여 대시보드 페이지를 본다"

describe('user login', function() {


  // 수행 및 결과 상태의 검증

  it('ensures user can log in', function() {

    // expect current scope to contain username

  });

  it('ensures path has changed', function() {

    // expect path to equal '/dashboard'

  });


});


  - 위의 테스트 Spec을 AngularJS로 통합 테스트 만들기 (참조)

    + 최근에는 Angular Scenario Test Runner와 같은 Protractor E2E test framework이 새롭게 소개되고 있다 

describe("Integration/E2E Testing", function() {


  // start at root before every test is run

  beforeEach(function() {

    browser().navigateTo('/');

  });


  // test default route

  it('should jump to the /home path when / is accessed', function() {

   // 루트 패스로 이동 - 로그인 화면 

    browser().navigateTo('#/');

    expect(browser().location().path()).toBe("/login");

  });


  it('ensures user can log in', function() {

    // 로그인 화면인지 체크

    browser().navigateTo('#/login');

    expect(browser().location().path()).toBe("/login");


    // assuming inputs have ng-model specified, and this conbination will successfully login

    // 테스트 데이터를 통해 브라우져 로그인 submit 버튼 click 이벤트 발생시킴 

    input('email').enter('test@test.com');

    input('password').enter('password');

    element('submit').click();


    // logged in route

    // 로그인이 성공했을 경우 대시보드 패스에 있는지 검증

    expect(browser().location().path()).toBe("/dashboard");


    // my dashboard page has a label for the email address of the logged in user

    // DIV의 id="email"의 html 값이 로그인시 입력한 값인지 검증 

    expect(element('#email').html()).toContain('test@test.com');

  });


  it('should keep invalid logins on this page', function() {

    // 로그인 화면 인지 검증

    browser().navigateTo('#/login');

    expect(browser().location().path()).toBe("/login");


    // assuming inputs have ng-model specified, and this conbination will successfully login

    // 잘 못된 값을 넣었을 가지고 로그인 버튼 클릭 

    input('email').enter('invalid@test.com');

    input('password').enter('wrong password');

    element('submit').click();


    // DIV id="message"에 failed메세지 있는지 검증 

    expect(element('#message').html().toLowerCase()).toContain('failed');


    // logged out route

    // 제대로 로그인을 못했으므로 로그인 패스 그대로인지 검증 

    expect(browser().location().path()).toBe("/login");

  }); // end it 

}); // end describe 



3. Mocking Services and Modules in AngularJS

  - 목(Mock) 서비스를 이용한 테스트 방법 

  - 목 오브젝트를 사용하는 이유는 외부적인 요소 의존적인 부분을 제거하고 테스트 하기 위해서 이다 

  - ngMock.$httpBackend : service에서 http login 호출을 하면 응답 JSON 객체를 넘겨주는 mock 객체를 만든다 

it('should get login success',

  inject(function(LoginService, $httpBackend) {


    $httpBackend.expect('POST', 'https://api.mydomain.com/login')

      .respond(200, "[{ success : 'true', id : 123 }]");


    LoginService.login('test@test.com', 'password')

      .then(function(data) {

        expect(data.success).toBeTruthy();

    });


  $httpBackend.flush();

});



<참조>

  - 원문 : Best Practices in AngularJS

  - AngularJS Controller Unit Test 방법

  - AngularJS Service Unit Test 방법

  - Full Spectrum Testing(E2E) in Angular with Karma (필독)

  - Introducing E2E Testing in Angular 동영상

    

posted by Peter Note
2013. 4. 3. 14:15 Testing, TDD/Test First

Node.js를 사용하기로 하면서 TDD를 위하여 Mocha를 선택하였다. 그리고 클라이언트단의 테스트 또한 Mocha로 이용해 보려 하였으나 DOM 조작이 많을 경우와 테스트 간결함등등에 강점이 많은 QUnit이 오히려 매력적으로 다가 왔다



1) QUnit vs Mocha

  - QUnit

    + DOM 조작관련 Client 단위 테스트에 적합

    + assert.equal이 아니라 equal만 사용하면 됨 

    + UI에서 테스트 모듈별로 콤보 선택하여 볼 수 있음

    + 클라이언트단 라이브러리들에서 주로 사용함 (BackboneJS 등)

    + PhantomJS와 연계하여 테스트

   



  - Mocha

    + 다양한 라이브러리를 접목 할 수 있다

    + 브라우져 UI 와 소스보기등이 QUnit 보다 나아 보임

    + equal 이 아니라 assert.equal을 씀 (assert의 경우) 즉, DRY 위배

    + UI에서 테스트 결과 전체가 리스팅 되고 선택하여 볼 수 없음 

 


** Backbone의 QUnit  코드를 Mocha를 가지고 메소드별로 TDD방식으로 테스트 해보았다. 라이브러리 테스트 코드를 하나하나 체크하면 전체 API의 동작방식을 심도 있게 이해 할 수 있다


https://github.com/ysyun/prototyping/tree/master/tdd/backbone-mocha/tests



2) 결론

  - 클라이언트 : QUnit + PhantomJS(CasperJS) 를 사용하여 테스트 진행

  - 서버 : Mocha + Assert 을 사용



<참조>

  - 원문 : Test  Libraries 비교 - 테스트 라이브러리별 사용처 권고함

posted by Peter Note
2013. 3. 20. 23:18 Testing, TDD/Test First

  TDD 또는 BDD로 진행을 하는 것은 소프트웨어의 명세를 만들어 가면서 보다 안정적인 서비스를 만드는 지름길이다. 물론 좀 더 시간을 투자해야하는 지름길이지만 나중의 유지보수를 생각하면 긴안목에서 역시 빠른 지름길이다. 특히 모바일 서비스의 경우는 몇번의 에러가 발생하면 사용자는 해당 앱을 삭제하고 절대로 사용하지 않는다는 보고가 있다. 그리고 페이스북에는 QA조직이 없고 개발자가 직접 모든 테스트를 수행하고 책임을 지도록 되어있다. 

  우리가 생산성을 위하여 프레임워크를 사용하듯, 안정성을 위해서는 테스트 코드가 필수이다. 또한 테스트 코드에 주석을 달고 Groc 같은 유틸로 문서화를 한다면 소프트웨어의 명세를 따로 하지 않아도 될 것이다. 

  백본기반의 개발에 있어서도 모델, 뷰, 라우터등의 TDD는 필요하며 이를 어떻게 하는지 따라해 보자



1) TDD 준비하기

  - backbone-mocha.zip 파일을 다운로드 받는다 

backbone-mocha.zip


  - tests/test-runner.html 을 수행한다 

  


  - test-runner.html 파일 이해

<!DOCTYPE html>

<html lang="en">

<head>

    <!-- Title &amp; Meta -->

    <title>Frontend tests</title>

    <meta charset="utf-8">


    <!-- Stylesheets -->

    <link rel="stylesheet" href="libs/mocha/mocha.css">

</head>

<body>


    <!-- mocha 결과 화면을 뿌리기 위한 div --> 

    <div id="mocha"></div>


    <!-- Testing Libraries 첨부 -->

    <script src="libs/mocha/mocha.js"></script>

    <script src="libs/chai/chai.js"></script>

    <script src="libs/sinon/sinon.js"></script> <!-- 본 예제에서는 sinon.js 안씀. 즉, 삭제가능 -->


    <!-- chai를 사용하고 mocha는 TDD를 사용한다. BDD는 bdd 소문자로 입력 

          TDD를 하면 mocha에서 suit(), setup(), teardown(), test() 4가지 메소드를 사용한다 

          첨부파일의 user.test.js 파일 참조


          chai는 should, expect, assert 방식을 선택할 수 있는데 여기서는 expect 방식을 선택

    -->

    <script>

        // Use the expect version of chai assertions - http://chaijs.com/api/bdd

        var expect = chai.expect;


        // Tell mocha we want TDD syntax

        mocha.setup('tdd');

    </script>


    <!-- 사용하는 Libs -->

    <script src="../libs/jquery/jquery-1.8.3.min.js"></script>

    <script src="../libs/underscore/underscore-min.js"></script>

    <script src="../libs/backbone/backbone-min.js"></script>


    <!-- 코딩한 원본 Source files -->

    <script src="../src/app.js"></script>

    <script src="../src/models/user.js"></script>

    <script src="../src/views/profile.js"></script>


    <!-- 개발한 소스와 맵핑되는 Test files -->

    <script src="models/user.test.js"></script>

    <script src="views/profile.test.js"></script>


    <!-- 최종적으로 mocha 를 수행한다 -->

    <script>

        mocha.run();

    </script>


</body>

</html>



2) Backbone Model TDD

  - tests/models/user.test.js 밑에 getFullName 테스트 코드 첨부

    + suite, setup, teardown, test : Mocha interface

    + expect : Chai interface

suite('User Model', function() {


    setup(function() {

        this.user = new app.models.User({

            first_name: "Yun",

            last_name: "DoWon"

        });

    });


    teardown(function() {

        this.user = null;

    });


    test('should exist', function() {

        expect(this.user).to.be.ok; // Tests this.user is truthy  <- chai 코드

    });


    test('calling getFullName should return first_name[space]last_name', function() {

        expect(this.user.getFullName()).to.equal('Yun DoWon');

    });


});

  

   - 호출하면 빨간색 Fail 발생

  - 에러 해결하여 초록 Green 으로 만들기위해 user.js 안에 getFullName 메소드 구현

(function(global, _, Backbone, undefined) {


    app.models.User = Backbone.Model.extend({

        getFullName: function() {

               // model 내역은 user.test.js의 setup에서 이미 설정해 놓았음

        return this.get('first_name') + " " + this.get('last_name');

        }

    });


})(this, _, Backbone);


  - 브라우져 호출 결과 : "User Model" 제목은 user.test.js 에서 지정한 제목임

  



3) Backbone View TDD

  - test/views 폴더 밑에 profile.test.js 파일을 만든다 

  - 다음 코드를 넣는다

suite('Profile View', function() {

 

    // Create a User model to pass into our view to give it data

    var model = new app.models.User({

        first_name: 'Yun',

        last_name: 'YoungSik',

        age: 23

    });

 

    setup(function() {

        this.profile = new app.views.Profile({

            // Pass in a jQuery in memory <div> for testing the view rendering

            el: $('<div>'), 

            

            // Pass in the User model 

            // dependency inversion makes this simple to test, 

            // we are in control of the dependencies rather 

            // than the view setting them up internally.

            model: model 

        });

    });

 

    teardown(function() {

        this.profile = null;

    });

 

    test('should exist', function() {

        expect(this.profile).to.be.ok;

    });

 

});


  - 브라우저에서 호출하기전 test-runner.html 에 profile.js 와 profile.test.js 를 넣는다

    <!-- Source files -->

    <script src="../src/app.js"></script>

    <script src="../src/models/user.js"></script>

    <script src="../src/views/profile.js"></script>


    <!-- Test -->

    <script src="models/user.test.js"></script>

    <script src="views/profile.test.js"></script>


  - 브라우져 호출 결과

  - src/views 폴더에 profile.js 파일을 생성하고 다음 코드는 넣고 다시 호출한다

(function(global, $, _, Backbone, undefined) {

 

    app.views.Profile = Backbone.View.extend({

 

    });

 

})(this, $, _, Backbone);

    

  - 정상 호출됨  

 


  - profile.test.js 안에 구현하고 싶은 다음 테스트 코드를 넣고 호출한다

    test('should exist', function() {

        expect(this.profile).to.be.ok;

    });

    // view 에 대한 render 테스트 : Regex 로 해당 내역이 화면출력으로 나왔는지 테스트

    test('render()', function() {

        this.profile.render();

     

        // 렌더링된 결과화면에 대하여 정규표현식으로 검사를 하는 것이 핵심!

        expect(this.profile.$el.html().match(/Yun/)).to.be.ok;

        expect(this.profile.$el.html().match(/YoungSik/)).to.be.ok;

        expect(this.profile.$el.html().match(/23/)).to.be.ok;

    });


  - profile.js 의 내역을 구현지 않았기 때문에 테스트에 대한 결과는 빨간색 fail 

  


  - profile.js 의 render() 메소드를 구현한다 

(function(global, $, _, Backbone, undefined) {

    app.views.Profile = Backbone.View.extend({

 

        render: function() {

            var html = "<h1>"+ this.model.getFullName() +"</h1>" +

                "<p>"+ this.model.get('first_name') +" is "+ this.model.get('age') + " years old";

            this.$el.html(html);

        }

 

    });

})(this, $, _, Backbone); 


  - 브라우져 호출 결과

  

 


테스트 코드를 만들고 실행하여 에러(빨간색)가 발생하면 테스트 코드에 대응하는 업무 코드를 짜고, 다시 실행하여 정상(녹색)적으로 돌아가게 한다. 정상에는 두 단계가 있는데, 비즈니스 로직이 없이 API와 정적값을 통해 정상(녹색) 통과를 하고 나면 이후 비즈니스 로직을 넣고 다시 정상(녹색) 통과를 하는지 체크한다. 



<참조> 

  - 원문 : Testing Backbone.js with mocha 

  - http://visionmedia.github.com/mocha/

  - http://chaijs.com/

posted by Peter Note
2013. 3. 13. 16:58 Testing, TDD/Test First

Backbone.js 번역서를 보던 중 코드를 테스트 해볼 수 있는 방법을 찾아 보았다. 백본이 브라우져에서 구동되는 SPA 라는 점을 감안한다면 브라우져 없이도 테스트 가능케 하는 방법으로 Casper.js 가 괜찮은 대안으로 보였다.  알아 볼까나~~~



1) Casper.js 란 무엇인가?

  - 클라이언트 사이드 화면에 대하여 PhatomJS 기반하에 자바스크립트 코드로 테스트를 좀 더 쉽게 만들어 주는 유틸리티이다

  - 따라서 사전에 PhantomJS는 설치되어 있어야 한다 (v1.7 이상, $ phantomjs --version 으로 확인)

  - UI 코드 테스팅이 가능하다 : 페이지 네비게이션, 이벤트, 폼 서밋, 화면 렌더링 이미지 캡쳐등이 가능 

  - 즉, 브라우져에서 사람이 하는 행위를 자동화 하여 수행할 수 있다

    


2) 설치하기 

  - GitHub 위치 : https://github.com/n1k0/casperjs

  - Mac : /usr/local/bin 은 .bash_profile 안에 PATH 걸려 있다는 가정

///////////////////////

// phantomjs 먼저 설치

1) 웹사이트에서 zip 파일 다운로드 

2) 심볼릭 링크 : phantomjs 디렉토리로 들어가서 설정한 것임 

$ ln -sf `pwd`/bin/phantomjs /usr/local/bin/phantomjs


///////////////////////

// casperjs 설치 

$ git clone https://github.com/n1k0/casperjs.git

$ cd casperjs/

$ git checkout tags/1.0.2

ln -sf `pwd`/bin/casperjs /usr/local/bin/casperjs



3) 사용하기

  - PhantomJS를 내부적으로 사용하기 때문에 팬텀의 기본 사용법을 익힌다  

    + 팬텀 v1.6 이상부터 자체 내장 모듈을 4가지를 가지고 있다. CommonJS Modules' Require (참조)

       1. webpage : var page = require('webapage').create(); 웹페이지 핸들링 추상화

       2. system : var system = require('system'); os 정보, pid 정보, cli 아규먼트 정보

       3. fs : var fs = require('fs'); 파일 시스템 핸들링, 디렉토리, 패스, 이름 정보

       4. webserver : var svr = require('webserver').create(); Mongoose 라는 자체 웹서버 내장


    + 여러 가지 예제들을 돌려보자 (예제 소스)


  - PhantomJS 간단 예제 

///////////////////////

// 테스트하고 빠져나오기 

// hello.js 코드

console.log("hi dowon");

phantom.exit();


// 결과 

$ phantomjs hello.js

hi dowon



//////////////////////

// URL 속도 측정

// loadspeed.js

var page = require('webpage').create(),

    system = require('system'),

    t, address;


if (system.args.length === 1) {

    console.log('Usage: loadspeed.js <some URL>');

    phantom.exit();

}


t = Date.now();

address = system.args[1];

page.open(address, function (status) {

    if (status !== 'success') {

        console.log('FAIL to load the address');

    } else {

        t = Date.now() - t;

        console.log('Loading time ' + t + ' msec');

    }

    phantom.exit();

})


// 결과 

$ phantomjs loadspeed.js http://www.google.co.kr

Loading time 1027 msec


  - CasperJS API의 예제를 돌려보자  

    + Casper API : var capser = require('casper').create(); 캐스퍼 생성, 로깅, 시작/종료/대기, 마우스이벤트, 페이지네비게이션

    + Client Side API : 에코, 인코딩, 북마크릿(웹킷기반 브라우져만), 폼/필드 값얻기(__utils__ 프로퍼티사용), 마우스 이벤트 

    + Colorizer API : var colorizer = require('colorizer').create('Colorizer'); 레벨에 따른 출력 색깔 표현

        casper.echo('text message', 'INFO'); // green

        casper.echo('text message', 'ERROR'); // red 

        미리 정의된 레벨과 컬러값 

        


    + Tester API :casper객체에 test 프로퍼티로 Tester 클래스 제공함. assert 계열 메소드, info 메세지 

var url = 'http://www.google.fr/';

var casper = require('casper').create();

casper.start(url, function() {

    this.test.assert(this.getCurrentUrl() === url, 'url is the one expected');

});

   + Utils API var util = require('utils')표준 자바스크립트 API 없는 것들 보충. isXX() 계열 메소드, dump하여 JSON 출력등 


  - CasperJS 간단 예제 

////////////////////////////////

// casperjs 사용하여 이미지 생성

// 객체 생성

var casper = require('casper').create({

    // 옵션적용

    onError: function(self, m) {   // Any "error" level message will be written

        console.log('FATAL:' + m); // on the console output and PhantomJS will

        self.exit();               // terminate

    }

});


// 지정 url 호출과 callback 지정 

// start 대신 open 을 통하여 POST, PUT, DELETE 값 전달도 가능 

casper.start('http://www.weather.com/', function() {

    this.captureSelector('weather.png', '#wx-main');

});


// 캐스퍼 수행하기  

casper.run();


// casper.run() 이 Async 구동이기 때문에 casper.exit(); 를 호출하면 이미지 생성전에 exit 됨 (호출하지 말것)

//casper.exit();  



4) Backbone.js 테스트 절차

나름 어떻게 테스트 해 볼 수 있을까 고민하다가 다음의 순서로 해보았고, 코드에 assert을 넣거나 응용을 하면 될듯하다  


  - 먼저 테스트 클라이언트 화면을 만든다 (index.html)

  - CasperJS 테스트 코드를 짠다 

  - 테스트를 위한 웹서버를 구동한다 (static 띄우기)

$ static

serving "." at http://127.0.0.1:8080

16:46:17 [200]: /index.html

16:46:17 [200]: /lib/jquery-1.8.2.min.js

16:46:17 [200]: /lib/backbone-min.js

16:46:17 [200]: /lib/underscore-min.js


  - 브라우져에서 확인(옵션)


  - CasperJS 테스트 수행하기 

$ casperjs  index_test.js

>> {"title":"","completed":false}

test done



5) Node 에서 단순 테스트 하기 

  - 백본을 노드에서 수행할 수도 있다. 어차피 자바스크립트이기 때문이다

  - 기본준비 : underscore.js, backbone.js 모듈을 node_modules 디렉토리방식으로 설치한다 

$ npm install underscore

$ npm install backbone


  - coffeescript 예제 코드 만들기 

Backbone = require 'backbone'


Todo = Backbone.Model.extend {

    # Todo에 대한 기본 속성

    defaults: {

      title: '',

      completed: false

    }

  }


Todos = Backbone.Collection.extend {

    model: Todo

  }


firstTodo = new Todo {title:'Read whole book'}


# 컬렉션 객체에 모델 배열을 전달한다.

todos = new Todos [firstTodo]

console.log todos.length


  - 수행 결과

// 커피파일 컴파일 

$ coffee -c *.coffee


// 노드로 수행 

$ node backbone_node.js

1



<참조>

  - Casper.js 홈페이지

  - NodeQA 사이트 소개글

  - Headless Integration Tests with CasperJS


posted by Peter Note
2013. 2. 16. 14:56 Testing, TDD/Test First

JavaScript 의 Unit Test를 위하여 여러 프레임워크가 나왔고, 이중 자유도가 높은 Mocha를 사용하려 한다. Assert에 대해 변경을 하면 BDD, TDD를 할 수 있고, JavaScript Funcational 프로그래밍 테스트에 잘 어울리는 BDD를 기본으로 사용한다



1. Test Framework의 종류 

  - Mocha의 장점이 가장 많다 (5page)



2. Mocha 

  - mocha 명령을 수행하는 위치 하위로 test디렉토리에 있는 스크립트를 자동 수행한다 

  - Assertion의 종류를 선택할 수 있다

    + should.js : describe, it 의 BDD 스타일

    + chai : expect(), assert() 스타일

    + expect.js : expect() 스타일 

  - should.js 는 Object prototype에 assert 모듈을 확장하였다 

  - test/mocha.opts 옵션 파일을 놓으면 자동 테스트시에 해당 옵션을 자동 적용한다

--require should
--reporter dot
--ui bdd
--globals okGlobalA,okGlobalB
--globals okGlobalC
--globals callback*

  --timeout 200


  - Mocha의 BDD 스타일 기본형식 

describe('BDD style', function() {

  before(function() {

    // excuted before test suite

  });

 

  after(function() {

    // excuted after test suite

  });

 

  beforeEach(function() {

    // excuted before every test

  });

 

  afterEach(function() {

    // excuted after every test

  });

   

  describe('#example', function() {

    it('this is a test.', function() {

      // write test logic

    });

  });

});




3. 사용법

  - test 폴더 밑에 mocha.opts 파일 작성

    + coffee-script 지원

    + requrie('should') 할 필요 없이 should.js 모듈 첨부

--compilers coffee:coffee-script

--require should


  - 간단한 테스트 프로그램 작성 

    + should.js API 익히기  : Object prototype을 확장하였으므로 Object.should 사용한다 (직관적인 표현이 좋군)

describe('Array', function() {

describe('#indexOf()', function() {

it('should return -1', function() {

[1,2,3].indexOf(5).should.equal(-1);

})

})

})


  -test 폴더와 같은 dept 위치에서 mocha 수행

[nulpulum:~/development/mongojs] mocha


  ․


  1 test complete (1 ms)



<참조>

  - Mocha 사용법 - Outsider

  - mocha.opts

  - 공식홈페이지 http://visionmedia.github.com/mocha/

  - Test Framework Pros and Cons 비교

posted by Peter Note
2013. 2. 7. 21:28 Testing, TDD/Test First

Mocha는 Node.js를 위한 테스트 프레임워크이다. test 스크립트가 변경되었을 때 계속 감시하면서 다시 mocha 테스트를 해주도록 Continuously Testing이 가능하도록 Nodemon을 적용해 본다


1) Mocha 와  Nodemon 설치하기 

  - mocha 설치

$ npm install -g mocha

npm http GET https://registry.npmjs.org/mocha

... 중략 ...

npm http 200 https://registry.npmjs.org/mkdirp/-/mkdirp-0.3.0.tgz

C:\Documents and Settings\UserXP\Application Data\npm\mocha -> C:\Documents and Settings\UserXP\Application Data\npm\node_modules\mocha\bin\mocha

C:\Documents and Settings\UserXP\Application Data\npm\_mocha -> C:\Documents and Settings\UserXP\Application Data\npm\node_modules\mocha\bin\_mocha

mocha@1.8.1 C:\Documents and Settings\UserXP\Application Data\npm\node_modules\mocha

├── growl@1.7.0

├── commander@0.6.1

├── diff@1.0.2

├── debug@0.7.2

├── ms@0.3.0

├── mkdirp@0.3.3

└── jade@0.26.3 (mkdirp@0.3.0)


  - nodemon 설치하기 

   + node.js를 기반으로 개발할  때 사용한다 

   + hang이 걸리면 자동으로 re-running 시켜준다

   + 여러 디렉토리를 감시할 수 있다 (--watch 옵션적용하면 내용 변경시 node auto restart)

$ npm install -g nodemon

npm http GET https://registry.npmjs.org/nodemon

npm http 200 https://registry.npmjs.org/nodemon

npm http GET https://registry.npmjs.org/nodemon/-/nodemon-0.7.2.tgz

npm http 200 https://registry.npmjs.org/nodemon/-/nodemon-0.7.2.tgz

C:\Documents and Settings\UserXP\Application Data\npm\nodemon -> C:\Documents and Settings\UserXP\Application Data\npm\node_modules\nodemon\nodemon.js

nodemon@0.7.2 C:\Documents and Settings\UserXP\Application Data\npm\node_modules\nodemon



2) Mocha 테스트 코드 만들기

  - mocha가 수행되는 위치의 test 디렉토리밑의 .js 파일을 자동 테스팅한다

  - BDD 테스트 코드 

  - mocha 수행 

// test 디렉토리가 존재 

$ ls

test


// mocha 명령을 수행하여 test 디렉토리의 mocha_sample.js 를 자동 수행하여 준다 

$ mocha


  .


  1 test complete (3 ms)



3) nodemon으로 mocha 수행하기 

  - nodemon을 mocha 위치를 지정하여 준다 

///////////////////////////////////

// 정상 테스트 코드

$ nodemon "C:\Documents and Settings\UserXP\Application Data\npm\node_modules\mocha\bin\mocha"

7 Feb 21:24:52 - [nodemon] v0.7.2

7 Feb 21:24:52 - [nodemon] watching: d:\Development\mocha

7 Feb 21:24:52 - [nodemon] starting `node C:\Documents and Settings\UserXP\Application Data\npm\node_modules\mocha\bin\mocha`


  .


  1 test complete (3 ms)


7 Feb 21:24:52 - [nodemon] clean exit - waiting for changes before restart


/////////////////////////////////////

// 코드를 수정하며 에러 발생

// indexOf(0) 을 indexOf(1) 변경

7 Feb 21:26:00 - [nodemon] starting `node C:\Documents and Settings\UserXP\Application Data\npm\node_modules\mocha\bin\mocha`


  .


  × 1 of 1 test failed:


  1) Array #indexOf() should return -1 when the value is not present:


  AssertionError: -1 == 0

      at Context.<anonymous> (d:\Development\mocha\test\mocha_sample.js:6:14)

      at Test.Runnable.run (C:\Documents and Settings\UserXP\Application Data\npm\node_modules\mocha\lib\runnable.js:213:32)

      at Runner.runTest (C:\Documents and Settings\UserXP\Application Data\npm\node_modules\mocha\lib\runner.js:343:10)

      at Runner.runTests.next (C:\Documents and Settings\UserXP\Application Data\npm\node_modules\mocha\lib\runner.js:389:12)

      at next (C:\Documents and Settings\UserXP\Application Data\npm\node_modules\mocha\lib\runner.js:269:14)

      at Runner.hooks (C:\Documents and Settings\UserXP\Application Data\npm\node_modules\mocha\lib\runner.js:278:7)

      at next (C:\Documents and Settings\UserXP\Application Data\npm\node_modules\mocha\lib\runner.js:226:23)

      at Runner.hook (C:\Documents and Settings\UserXP\Application Data\npm\node_modules\mocha\lib\runner.js:246:5)

      at process.startup.processNextTick.process._tickCallback (node.js:244:9)


7 Feb 21:26:01 - [nodemon] app crashed - waiting for file changes before starting...


  - 위의 명령을 넣고 C:\Documents and Settings\UserXP\Application Data\npm\cmocha.cmd 파일을 만든다

  - cmocha.cmd를 수행하면 위와 똑같이 수행위치 하단에 test 디렉토리가 있다면 continuous mocha를 수행한다 



<참조>

  - 원문 : Automating Testing with Mocha and WebStorm

  - Mocha 소개

posted by Peter Note
2013. 1. 8. 21:54 Testing, TDD/Test First

1) Clean Code를 만들기 위한 Unit Testing에 대한 이해


2) Test Driven Development(TDD)를 위한 Unit Testing

* 2)번 슬라이드중 TDD를 가장 잘 설명한 그림 : 설계->Test(Fail) -> 구현 -> Test(Success)



3) Unit Testing을 위한 가장 효과적인 방법들


4) 테스트를 위한 도구들에 대한 생각


* 4) 슬라이드에서 나온 도구 그림

posted by Peter Note
2012. 11. 9. 16:23 Testing, TDD/Tools, FitNesse

간단하게 특정 URL에 대한 성능 측정을 Command Line에서 수행하고 결과를 얻을 수 있는 툴로 Apache Benchmark가 있다. 손쉽게 사용해 보자


  • 테스트 url의 결과값을 확인해 보자 : curl <URL> 
  • 성능을 측정해 보자 : ab <Options> <URL>


* 참조 : ab 사용법




posted by Peter Note
2012. 10. 26. 21:46 Testing, TDD/Tools, FitNesse

JMeter를 통하여 검색인자에 대하여 동적인 값을 넣어주고 싶을 경우 부하를 어떻게 주는지 보도록 하자. 동적인 인자 값을 txt로 설정하고 불러와서 자동으로 인자값을 바꾸어 준다.



▶ search.txt에서 인자값을 읽어서 동적으로 search 파라미터를 바꾸어서 부하주기 

  1. CSV Data Set Config를 추가 한다

  2. 동작으로 넣어줄 search.txt 파일을 만든다 (각 인자값은 \r\n)


  3. 만든 search.txt 파일 경로를 CSV Data Set Config 에 절대경로 위치를 설정한다

  4. "Google Search"에서 레코딩한 "/search" 의 HTTP Request의 Parameters 값으로 static하게 설정된 "beethoven"을 ${search_name}이라 설정한다
     
  5. Response Assertion에도 beethoven으로 설정된 값을 동일하게 ${search_name} 이라 고쳐준다

  6. 결과 값을 보기위하여 Debug Sampler를 추가한다. 그리고 하위로 View Results Tree 를 추가하여 결과 내역을 상세히 본다


  7. View Results Tree의 상세 내역을 보면 HTTP Response data로 search_name=Morzart 등등 변경되어 인자값이 전달된 것을 볼 수 있다

  8. Run/start를 수행하면 7번과 같은 결과를 볼 수 있다

JMeter의 왼쪽 Tree Menu는 위에서 부터 아래로 순차적으로 수행이 된다. 따라서 각 Tree Node를 마우스 Drag&Drop으로 원하는 위치로 이동을 할 수 있다. Add를 잘 못 하였더라도 위치조정을 하면 된다

BeanShell을 이용하게 되면 프로그래밍적인 Controller를 추가할 수 있고, 트리메뉴의 순서를 변경하면 순차적으로 수행을 한다. BeanShell 사용은 다음에 살펴보자.


posted by Peter Note
2012. 10. 26. 19:46 Testing, TDD/Tools, FitNesse

JMeter에 Thread Group을 "Google Search"로 설정하고, WorkBeanch에서 레코딩 작업을 "Goolge Search"에 해준후 부하를 어떻게 쏘고 결과를 보는지 알아보자 



▶ 부하 주기 

  1. Assertion을 설치하여 결과값이 제대로 레코딩된 것인지 확인 할 수 있다 ([Add] 버튼 클릭후 입력값 beethoven 넣음)



  2. 결과를 Graph Result로 보기위하여 추가한다

  3. Thread Group의 user 수를 100으로 한다


  4. 상단의 메뉴 Run/Start를 수행한다


  5. Graph Results 를 통하여 결과 성능을 볼 수 있다. (X축 : 동시 접속자수, Y축 : 응답시간)
    성능그래프는 어차피 x축 동접수 대비 y축의 최대 응답시간의 직교점을 찾으면 된다.

  6. Summary Report를 통하여 에러와 결과값을 수치로 확인한다



가장 간단하게 성능 테스트 하는 것을 보았는데, 예전에 사용한 MS Stress Test Tool과 유사하다. 하지만 Thread Group의 Add 항목에 있는 기능들을 보면 스크립트를(BeanShell) 이용하여 동적인 아규먼트를 주거나 다양한 프로토콜 (FTP, TCP, LDAP 등등) 을 지원한다. 따라서 사용수준의 사용법을 익히 알고 있는 엔지니어라면 -예로 LoadRunner- JMeter를 사용하는데 큰 어려움을 없을 것으로 생각된다. 


posted by Peter Note
2012. 10. 26. 11:37 Testing, TDD/Tools, FitNesse

JMeter를 순수 Java 기반의 성능 테스트 툴이다. 아파치의 설명을 보자 


The Apache JMeter™ desktop application is open source software, a 100% pure Java application designed to load test functional behavior and measure performance. It was originally designed for testing Web Applications but has since expanded to other test functions.



▶ JMeter를 사용해 보자 


  1. JMeter 사이트에서 최신 버전을 다운로드 받는다 ( http://jmeter.apache.org/download_jmeter.cgi )
  2. 로컬에 압축 파일을 풀고, D:\apache-jmeter-2.8\bin\jmeter.bat 를 실행한다

  3. 사용자(=Thread) Group를 생성한다 : 이것은 요청하는 사용자의 요청 방법을 설정한다 (명칭을 Google Search 로 수정)
    1. Number of Thread : 동시 사용자 수
    2. Ramp-Up Period : 사용자가 하나씩 들어갈 때 시간 간격
    3. Loop Count : 테스트 시나리오를 몇 번 실행할 것인지



  4. WorkBench에서 Http Proxy Server를 선택한다

  5. 브라우져에서 웹사이트를 Recording할 때 사용하는 로컬 프락시 임의 포트를 9090으로 설정하고 Thread Group으로 설정한 Google Search를 선택한다

  6. 이제 Recording을 위하여 FireFox 브라우져를 설치하고, FireFox에 Proxy 사용 및 Port를 9090으로 설정한다 



  7. 불여우창에서(ㅋㅋ) 구글 사이트로 들어가서 임의 검색어를 넣고 검색을 하기전에 위 5번 화면의 하단 [Start] 버튼을 클릭한다. [Start] 버튼을 클릭후 불여우창에서 보는 모든 웹요청은 JMeter로 Recording이 된다

  8. 원하는 웹요청을 다 하였다면 JMeter창에서 [Stop] 버튼을 클릭하여 Recording을 멈춘다 

  9. Recording이 끝나면 다음과 같이 레코딩된 내역을 볼 수 있다
  10. 다음에 부하를 준다. (다음 블로그에서...)


posted by Peter Note
2012. 10. 25. 20:34 Testing, TDD/Test First

1) JUnit을 통하여 단위테스트 하는 방법에 대한 참조 사이트들

  - JUnit 기본 사용하기 : http://blog.daum.net/aqua0405/5558279

  - JUnit 단축키 : alt + shift + x 그런후 t 클린하면 JUnit Test가 진행

  - Spring에서 JUnit :  http://blog.sangpire.pe.kr/125

  - Mock 객체 사용하기 :  http://javacan.tistory.com/148

  - DBUnit 사용하기 :  http://www.java2go.net/blog/tag/Testing


2) JUnit 테스트 순서

  - @Test 안에 계약에 의한  설계에 따른 테스트를 만든다

  - ctrl + 1 로 실제 업무 클래스를 생성하여 로직 실패를 만든다

  - 실패한 코드를 확인후 기능이 돌아가는 코드를 짠다

  - 다시 테스트를 돌려본다

  - 추상화가 필요할 경우 추상클래스를 테스트 코드에 넣고, 하위 클래스의 메소드를 pull up하는 리팩토링을 수행한다

  - 테스트 코드안에서 계약에 의한 설계와 OOP와 Refactoring을 계속 하면서 결과값을 검증한다.

  - 이를 계속 반복한다 


3) JUnit에 대한 개념 잡기 슬라이드 


posted by Peter Note
2012. 10. 24. 21:14 Testing, TDD/Tools, FitNesse

▶ Fit으로 테스트 했던 CalculateDiscount를 FitNesse Wiki에 넣어 보자 


  1. CalculateDiscount wiki 페이지를 만들어준다

  2. Excel을 이용하여  CalculateDiscount  표를 작성한다 (상단의 명칭은 java 클래스 명칭과 동일하게 작성한다)
 

  3. CalculateDiscount wiki 페이지에 excel 표를 Copy&Paste하고 [SpreadSheet to FitNesse] 포멧으로 바꾸고 [Save] 한다

  4. 기존에 만들어 두었던  CalculateDiscount java 컴파일 내역을 fitnesse.jar 파일 있는 곳에 복사한다

  5. [Test] 버튼을 클릭하여 테스트를 수행한다

  6. 결과를 확인한다



▶ Fit 과 FitNesse 응용하기 


  - Fit 방식을 이용하여 Maven에서 자동화 테스트 구현을 한다. 결과 result.html을 웹서버로 서비스하게 만들어 준다

  - FitNesse는 고객이 FrontPage로 들어와서 위키페이지 마다 [Test]를 클릭하여 결과를 직접 확인 하는 방법도 있다. 

posted by Peter Note
2012. 10. 24. 20:52 Testing, TDD/Tools, FitNesse

▶ FitNesse 를 설치하고 웹상에서 테스트하기 


  1. http://www.fitnesse.org/  로 들어가서 fitnesse.jar 파일을 다운로드 받는다

  2. 특정 디렉토리에 복사를하고 classpath 환경변수에 잡아준다. (안 잡을 경우 java -classpath에서 잡아줌)

  3. listen port를 지정하고 fitnesse 서버를 기동시킨다

  4. 브라우져에서 확인한다. FitNesse는 Wiki Web Server 이다. 여기에 Fit 테스트를 결합 시켰다.


  5. Main 페이지에서 왼쪽 메뉴에서 [Edit] 를 클릭한다
 

  6. Editing 페이지 하단에 >TestSample 이라고 입력하고 Save한다

  7. 화면의 하단의 TestSample[?] 에서 링크된 ? 를 클릭한
.
  8. TestSample Wiki 페이지가 나온다. 

  9. Excel을 이용하여 StressTest Column Fixture를 만든다.  (상단의 명칭은 java 클래스 명칭과 동일하게 작성한다) 

  10. TestSample Wiki 페이지 왼쪽 메뉴 [Edit] 클릭하여 들어간다. 
  11. 편집모드에서 상단에 fitnesse.jar 파일이 있는 위치정보를 넣어주고, Excel표는 Copy하여 Paste 한후에 [SpreadSheet to FitNesse] 버튼을 클릭한다. 그러면 Excel 포멧이 FitNesse 포멧으로 변경된다. 그리고 [Save] 한다. 


  12. 저장한 화면이 다음과 같이 나온다
 

  13. 왼쪽 메뉴 [Properties]에서 Test 속성을 체크하고 [Save] 한다


  14. StressTest.java 파일을 작성한다

  15. StressTest.java파일은 fitnesses.jar 파일이 있는 곳에서 컴파일 한다 

  16. 이제 모든 준비가 끝났다. 

    - 샘플 wiki 페이지를 만듦

    - 샘플 wiki 내용에 인수 테이블 포멧 Copy&Paste from Excel

    - Java Fixture를 만들어서 Fitnesse.jar 파일위치에서 컴파일

  17. 다음에 TestSample 페이지의 [Test] 버튼을 클릭한다

  18. 결과값이 자동으로 출력된다


한번의 스텝이 돌았다. 이제 FrontPage 메인에 또 다른 테스트 케이스를 > 를 이용하여 넣고서 첨부 할 수 있다. 

'Testing, TDD > Tools, FitNesse' 카테고리의 다른 글

[JMeter] 성능 테스트툴 간단 사용기-1  (0) 2012.10.26
[테스트 실습-3] FitNesse-2  (0) 2012.10.24
[테스트 실습-2] Fit-3  (0) 2012.10.23
[테스트 실습-2] Fit-2  (0) 2012.10.23
[테스트 실습-2] Fit-1  (1) 2012.10.23
posted by Peter Note
2012. 10. 23. 22:20 Testing, TDD/Tools, FitNesse

▶ Batch나 업무 프로세스를 타고 Fit Testing  (Action Fixture)

  - start   : 실행 fixture를 자동화할 클래스 명칭을 얻고 테스트를 시작한다

  - check : 메소드를 수행하여 값을 검증한다

  - enter  : 어떤 테스트도 하지 않고 void 메소드를 수행한다

  - press : 메소드를 수행하고 인수(argument)를 전달한다


  1. word로 위에서 부터 아래로 쭉 실행할 내역을 적는다 (start : BuyActions 란 명칭으로 주고 java파일도 동일하게 작성)

  2. java 파일을 하기와 같이 작성한다  

  3. java 파일 컴파일 하고, java fit.FileRunner TestBuyItems.htm result.html 수행한다

  4. 결과 result.html 을 열어본

▶ Action Fixture를 이용한 Chat Server 테스트 

  

  1. word에서 html 파일 만들기



  2. java로 Fixture 개발 (Fixture-ChatServerActions, 업무 모듈-ChatRoom, User, Room) 

  3. java 파일 컴파일하고, java fix.FileRunner TestChatServer.htm result.html 명령 수행하기 

  4. 결과  result.html 열어보기
 

▶ 예제 파일


TestCase-4.zip


TestCase-5.zip



▶ 참고 

  - Fit 의 Fixture 를 wiki에서 사용하는 방법 및 코드 

  - eclipse에서 Fit을 자동화 테스트 하고 싶을 경우 (luxoft)

  - eclipse FitRunner plug-ins 테스트 하기 


'Testing, TDD > Tools, FitNesse' 카테고리의 다른 글

[JMeter] 성능 테스트툴 간단 사용기-1  (0) 2012.10.26
[테스트 실습-3] FitNesse-2  (0) 2012.10.24
[테스트 실습-3] FitNesse-1  (0) 2012.10.24
[테스트 실습-2] Fit-2  (0) 2012.10.23
[테스트 실습-2] Fit-1  (1) 2012.10.23
posted by Peter Note
2012. 10. 23. 21:58 Testing, TDD/Tools, FitNesse

▶ 다수 인수에 대한 Fit Testing (Column Fixture)


  1. word에서 다음과 같이 fixture를 만들어 본다


  2. java 파일을 코딩한다 



  3. javac *.java 명령으로 컴파일 한다 

  4. java fit.FileRunner CalculateCredit.htm result.html 명령을 수행한다 

  5. result.html 파일을 열어본다 


▶ 인수값 열거형 Fit Testing (Column Fixture)


  1. word에서 열거를 위하여 콤마(,)를 사용한다. TestFirstPhone.htm으로 저장한다 

  2. java 코딩을 하기와 같이 한다


  3. java파일을 컴파일 한다

  4. java fit.FileRunner TestFirstPhone.htm result.html 수행한다 

  5. 결과를 열어본다


열거형등 다양한 타입에 대한 테스트를 수행해 볼 수 있겠다. 


▶ 예제 파일


'Testing, TDD > Tools, FitNesse' 카테고리의 다른 글

[JMeter] 성능 테스트툴 간단 사용기-1  (0) 2012.10.26
[테스트 실습-3] FitNesse-2  (0) 2012.10.24
[테스트 실습-3] FitNesse-1  (0) 2012.10.24
[테스트 실습-2] Fit-3  (0) 2012.10.23
[테스트 실습-2] Fit-1  (1) 2012.10.23
posted by Peter Note
2012. 10. 23. 20:55 Testing, TDD/Tools, FitNesse
▶ Test Framework 갖추기  

  - 형상관리 -> CI (빌드) -> 테스트 서버로 애플리케이션이 배포된 후 애플리케이션에 대한 자동화 테스트 수행

  - 테스트 서버에서 자동 테스트를 위한 Test Framework이 필요

    + DB schema의 최기화/원복 : DBA 하지 말고, DDL 가지고 테이블 관리 

    + 입력 파라미터 공급

    + 테스트 케이스에 대한 오류를 개발자 포털에 자동 등록 및 메일링 : 개발자 feedback 필요 (jira 자동 등록)

    + 테스트 서버 = HW/DB + Real Framework + Test Framework + 애플리케이션 + 테스트 코드 + 테스트 실행 stack이 필요함 


대부분 형상관리서버+빌드시스템까지는 구축하지만 적절한 Test Framework을 갖추는 것이 핵심이다. 



▶ 참조사이트

Using Fit Open Source Framework

Test Frameworks

Fitness


▶ Fit Test 하기 

  1. PC Local에 JDK 설치한다. 

  2. JDK bin 디렉토리는 환경변수 path에 설정한다. 

  3. Fitness를 다운로드한다. :  http://fit.c2.com/wiki.cgi?DownloadNow  -> JavaPlatform

  4. fit-java-1.1.zip파일 압축을 풀면 폴더안에 : fit.jar 파일이 있다. 

  5. fit.jar 파일을 환경변수에 classpath = .;<directory>\fit.jar  설정을 한다. (설정하지 않으면 java 수행시 -classpath를 늘 잡아준다)

  6. word를 열어서 다음과 같이 표를 만들어 .htm으로 저장한다 

  7. java 파일을 하기와 같이 만든다. (주의:htm파일 내역중 fixture명칭 CalculateDiscount 명칭과 java파일 명칭과 일치해야함)

  8. eclipse에 만든 *.java 파일을 TestDiscount.htm 파일이 있는 곳에 위치 시킨다. 예) d:/Test_framework/fit_testing/TestCase-1

  9. d:/Test_framework/fit_testing/TestCase-1 > javac *.java  명령으로 java 파일을 컴파일 한다. 
  10. d:/Test_framework/fit_testing/TestCase-1 > java fit.FileRunner TestDiscount.htm result.htm 명령을 수행한다.



  11. 결과 result.htm 파일을 열어본다. 

  12. 1000에서 결과값을 0.00 으로 기대했지만 50.0 값이 나왔고, 밑에도 50.51을 기대했지만 50.5가 나와서 amount라는 인수값을 discount()라는 메소드에 대입하였을 때 인수 테스트 2개에 오류 (2 wrong)가 있었음을 result.htm 결과 화면에 표현해 준다. 


▶ 결과 파일 


'Testing, TDD > Tools, FitNesse' 카테고리의 다른 글

[JMeter] 성능 테스트툴 간단 사용기-1  (0) 2012.10.26
[테스트 실습-3] FitNesse-2  (0) 2012.10.24
[테스트 실습-3] FitNesse-1  (0) 2012.10.24
[테스트 실습-2] Fit-3  (0) 2012.10.23
[테스트 실습-2] Fit-2  (0) 2012.10.23
posted by Peter Note
2012. 10. 22. 19:51 Testing, TDD
▶ 테스트의 일반적인 사항
  • 테스트 : 결함을 찾아 내는 것 (정치적으로 이용하게 되면 회비용 도구가 될 수도 있다)
  • QA : 기능상 정상 작동함을 증명 
  • 설계:개발:테스트 = 30:30:40 노력 분포도 
  • 테스트는 개발 초기에 수행
  • 1시간 이상 테스트에 몰두 하지 말라 (살충제 패러독스 : 결함에 내성이 생겨서 못찾는다. 쉬면서 또는 동료검토)
  • QC가 테스트와 비슷하고 QA와 테스트는 틀리다. 즉, QC & 테스트는 개발자나 PMO가 진행할 수 있다. 
  • UI 테스트 말고 핵심 로직에 대한 테스트를 얼마나 효과적으로 하는가가 중요함 
  • 단위 테스트 -> 통합 테스트 -> 시스템 테스트 -> 인수 테스트 -> 설치 테스트 : 단위 테스트가 제일 중요하다. 



'Testing, TDD' 카테고리의 다른 글

On Going Reliability Test란 무엇인가?  (0) 2012.08.17
posted by Peter Note
prev 1 2 next