Test는 필요한가?

Test는 정말 필요한가?

사례 A

경력 10년차 프로젝트 구성원이 코드를 수정했다.

이를 믿을 수 있나?

사례 B

새롭게 투입된 경력 10년차 개발자가 코드를 수정했다.

이를 믿을 수 있나?

사람 프로세스를 통해 검증

QA나 개발자가 직접적으로 변경 부분에 대해 side-effect를 실제 테스트하여 확인한다.

리소스가 많이 든다.

QA 담당자의 역량에 의해
테스트 검증 여부가 결정된다.

새로운 경력 1년차 개발자가 코드를 수정했다.

신입 프로젝트 구성원이 코드를 수정했다.

이를 믿을수 있나?

테스트 코드만 있다면

믿을수 있습니다.

테스트 코드는

빠른 피드백을 준다.

개발(action) -> 테스트 (effect)->
피드백 -> 개발 -> 테스트 -> 피드백 ...

또한, 테스트 코드는

미래를 위한 안전핀을 제공한다.

• 코드 변경도 겁나지 않아요.
• 회기 테스트도 순식간에 할수 있어요.

이런 장점이 있음에도

왜?

우리는 테스트 코드를 만들어 내지 못하고 있는가?

문제는 단연코 시간!

서비스 일정은 정해졌지만, 스펙은 계속 늘어나고,
늘어나기만 하면 괜찮지만, 다 바꾸기까지하죠.

테스트 코드는 산출물이 아닌
하나의 서비스이다.

인식. 프로세스의 변화가 필요

관리가자 보는 "개발 끝!의 의미"

설계 + 구현 + 테스트 코드 작성

개발자가 보는 "테스트 코드의 시각"

소스와 같이 소중히...

• 유지보수를 위해 읽기가 쉬워야한다.
• 리팩토링이 필요하다.
• 형상관리...

품질관리가 보는 시각

품질 관리의 시작은 QA 시작부터가 아닌,

테스트 코드 부터...

이러한 마음의 자세가 되었다면...

좀 더 자세히 이야기해보자.

개발 프로세스

애자일 방법론에서 사용하는 X-Driven Development 방식

• TDD(Test-Driven Development)
• BDD(Behavior-Driven Development)

둘 다 차이가 없음. 단, BDD는 비즈니스 요구사항 중심적. (좀더 자연어에 걸맞게)

TDD와 BDD 프로세스

테스트 First. 실패 First

Red - Green - Refactor의 반복

좋은 테스트 코드

• 하나의 테스트는 한가지 기능에 충실
• A 테스트는 B 테스트에 영향을 미치면 안된다.
• 테스트 전과 후의 상태가 변경되면 안된다.
• 테스트는 여러번 수행해도 같은 결과를 출력해야한다.

Funtional Programming ?

테스트 코드 작성 방법

1. 사용자 요구사항 관점에서 명세를 만든다
2. Given/When/Then 패턴으로 테스트 시나리오를 작성
3. 코드로 옮김

1. 명세를 만든다

사용자 관점의 명세를 만든다.

숫자가 3으로 나누어지면 결과값은 "Fizz"
숫자가 5로 나누어지면 결과값은 "Buzz"
숫자가 3과 5로 나누어지면 결과값은 "FizzBuzz"

2. Given/When/Then pattern으로

시나리오 작성

http://martinfowler.com/bliki/GivenWhenThen.html

• Given : 테스트 전의 상태
• When : 테스트 행위
• Then : 테스트 결과 검증

3. 코드로 옮김

테스트 프레임워크 : jasmine, qunit, mocha

mocha는 별도의 assertion 모듈(chai, should, expect)이 필요함

Jasmine Test Framework

jasmine document

describe("the name of test suite", function() {
  beforeAll(function() {}); // suite 전에 호출
  afterAll(function() {});    // suite 후에 호출
  beforeEach(function() {})    // 각각의 spec 전에 호출
  afterEach(function() {})    // 각각의 spec 후에 호출
  it("should/contains ... spec1 ", function() {
      // except(value).matchers
      except(true).toBe(true);
      except(true).not.toBe(false);
  });
  it("should/contains ... spec2 ", function() {
    except(true).toEqual(true);
  })
  // ...
});

RED 테스트 코드를 만든다.

Given/When/Then 패턴으로 작성한다.

describe("FizzBuzz", function() {
  it("should return 'Fizz' when the number is divisible by 3", function() {
      // Given
      // When
      // Then
  });
})

테스트 코드를 작성한다.

describe("FizzBuzz", function() {
  it("should return 'Fizz' when the number is divisible by 3", function() {
      // Given
      var fizzBuzz = new FizzBuzz();

      // When
      var result = fizzBuzz.call(3);

      // Then
      expect(result).toEqual("Fizz");
  });
})

테스트가 실패 했다.

Green 테스트를 통과하게 한다.

코드를 수정한다.

function FizzBuzz() {}

FizzBuzz.prototype.call = function(num) {
    return "Fizz";
}

테스트가 성공 했다.

Refactor 코드를 개선한다.

function FizzBuzz() {}

FizzBuzz.prototype.call = function(num) {
    if (num % 3 === 0) {
        return "Fizz";
    }
}

Demo

테스트는 쉽다?

테스트 하기 어려운 코드

$(document).ready(function(){
  var div1 = $('div.one'),
      itemCount = getItemCount('li.item'),
      value = window.scrollTop;

  div1.on('click',function(){ //... });

  function getItemCount(selector) {
    return $(selector).length;
  }
});

테스트 하기 좋은 코드

• 객체/함수/메소드의 노출
• 의존 객체의 주입
• 속성의 노출은 지양

Loosely Coupling. Modular

var app = {
  init : function(global){
       this.value = global.scrollTop
     div1.on(
        'click', this.handleDivClick
     );
     this.itemCount = this.getItemCount( 'li.item' );
  },

  getItemCount : function( selector ){
    return $( selector ).length;
  },

  handleDivClick : function( e ){
    this.global.scrollTop
  }
};

테스트 하기 좋은 코드는

Test Double을 사용할 수 있다.

Test double : 테스트시에 실제 객체를 대신 할 수 있는 객체

Test Double

• Spy : 멤버가 올바르게 호출 되었는지 확인.
• Stub : 로직이 없고, 원하는 값만 반환.
• Mock Object
  “어떤 메소드가 호출 될 것이다”라는 행위에 대한 예상들을 예측하여 미리 프로그래밍한 객체
• Fack Object : 거의 완전한 구현체

spy 구현하기

spyOn, createSpy, createSpyObj 를 사용

describe("A spy", function() {
  it("tracks that the spy was called", function() {
    // Given
    var foo = {
        getBar: function() {
            return bar;
        }
    };
    spyOn(foo, "getBar");
    // When
    foo.getBar();
    // Then
    expect(foo.getBar).toHaveBeenCalled();
  });
});

stub 구현하기

and.returnValue, and.callFack 등을 사용

describe("A spy, when configured to fake a return valu", function() {
  it("when called returns the requested value", function() {
    // Given
    var foo = {
        getBar: function() {
            return bar;
        }
    };
    spyOn(foo, "getBar").and.returnValue(745);
    // When
    var bar = foo.getBar();
    // Then
    expect(bar).toEqual(745);
  });
});

자주 사용하는 테스트 유형

• 비동기 테스트
• setTimeout 테스트
• Ajax 테스트 (jasmine-ajax)
• DOM 테스트 (jasmine-dom)
• Global 객체 테스트

비동기 테스트

• 첫번째 파라미터로 done 함수가 전달됨

  it("should support async", function(done) {
    // ...
  });
  

• 비동기 작업이 완료되었을 경우, done을 호출

  done();
  

describe("Asynchronous specs", function() {
  var value;
  it("should support async execution", function(done) {
    // Given
    value = 100;
    expect(value).toEqual(100);
    // Then
    setTimeout(function() {
      expect(value).toEqual(101);
      done();
    },100); // 100ms 대기
    // When
    value++;
  });
});

setTimeout 테스트

• timer mocking

  jasmine.clock().install();
  jasmine.clock().uninstall();
  

• createSpy로 감시할 함수 생성.

  timerCallback = jasmine.createSpy();
  setInterval(function() {
    timerCallback();
  }, 100);
  

• jasmine.clock().tick 메소드로 timer 이동

  jasmine.clock().tick(time);
  

describe("Manually ticking the Jasmine Clock", function() {
  var timerCallback;
  beforeEach(function() {
    timerCallback = jasmine.createSpy();
    jasmine.clock().install();  // timer mocking start
  });
  afterEach(function() {
    jasmine.clock().uninstall();  // timer mocking end
  });

  it("causes a timeout to be called synchronously", function() {
    // Given
    setTimeout(function() {
      timerCallback();
    }, 100);
    expect(timerCallback).not.toHaveBeenCalled();
    // When
    jasmine.clock().tick(101);
    // Then
    expect(timerCallback).toHaveBeenCalled();
  });

  it("causes an interval to be called synchronously", function() {
    // Given
    setInterval(function() {
      timerCallback();
    }, 100);
    expect(timerCallback).not.toHaveBeenCalled();

    // When
    jasmine.clock().tick(101);  // 101
    // Then
    expect(timerCallback.calls.count()).toEqual(1);

    // When
    jasmine.clock().tick(50);   // 151
    // Then
    expect(timerCallback.calls.count()).toEqual(1);

    // When
    jasmine.clock().tick(50);   // 201

    // Then
    expect(timerCallback.calls.count()).toEqual(2);
  });
});

Ajax 테스트 jasmine-ajax

• ajax mocking

  jasmine.Ajax.install();
  jasmine.Ajax.uninstall();
  

• 특정 url에 대한 결과값을 반환하는 stub 생성

  jasmine.Ajax.stubRequest('/another/url').andReturn({
    "responseText": 'immediate response'
  });
  

• createSpy로 감시할 함수 생성.

  done = jasmine.createSpy();
  xhr.onreadystatechange = function(args) {
    if (this.readyState == this.DONE) {
      done(this.responseText);
    }
  };
  

describe("mocking ajax", function() {
  describe("suite wide usage", function() {
    beforeEach(function() {
      jasmine.Ajax.install();
    });
    afterEach(function() {
      jasmine.Ajax.uninstall();
    });
    it("allows responses to be setup ahead of time", function () {
      // Given
      var doneFn = jasmine.createSpy();
      jasmine.Ajax.stubRequest('/another/url').andReturn({
        "responseText": 'immediate response'
      });
      var xhr = new XMLHttpRequest();
      xhr.onreadystatechange = function(args) {
        if (this.readyState == this.DONE) {
          doneFn(this.responseText);
        }
      };

      // When
      xhr.open("GET", "/another/url");
      xhr.send();

      // Then
      expect(doneFn).toHaveBeenCalledWith('immediate response');
    });
  });
});

DOM 테스트 jasmine-jquery

• 테스트할 fixtures(HTML)를 설정

  setFixtures(sandbox());
  loadFixtures("domtest.html");
  

• DOM을 컨트롤 한다. (jquery)
• DOM Matchers를 통해 테스트 한다.

  expect($('#sandbox'))
    .not.toHaveClass('TestClass');
  expect('click')
    .toHaveBeenTriggeredOn('#sandbox');
  

describe("Using sandbox", function() {
    it ("should remove a class", function() {
        // Given
        setFixtures(sandbox({class: 'TestClass'}));
        expect($('#sandbox')).toHaveClass('TestClass');

        // When
        $('#sandbox').removeClass("TestClass");

        // Then
        expect($('#sandbox')).not.toHaveClass('TestClass');
    });

    it ("should invoke the btnShowMessage click event.", function() {
        // Given
        setFixtures(sandbox());
        var spyEvent = spyOnEvent('#sandbox', 'click');

        // When
        $('#sandbox').trigger( "click" );

        // Then
        expect('click').toHaveBeenTriggeredOn('#sandbox');
        expect(spyEvent).toHaveBeenTriggered();
    });
});

Global 객체 테스트

window, document 테스트

• window, document와 같은 객체를 주입할수 있도록 구성

  function service_mod = function(global, doc) {
  // ...
  };
  

• 테스트할 부분에 대한 Mock Object를 주입한다.

service_mod({
  navigator: {
    userAgent: "Mozilla/5.0 (iPhone; CPU iPhone OS 9_0 like Mac OS X) AppleWebKit/601.1.46 (KHTML, like Gecko) Mobile/13A452 Safari Line/5.4.0"
  }, document
})

소스는 global 객체를 주입할 수 있게 구성한다.

var agent = function(global) {
  return /iPhone|iPad/.test(global.navigator.userAgent) ?
    "ios" : "android";
};

테스트에서는 Mock 객체를 주입하여 테스트 한다.

describe("Using sandbox", function() {
    it ("should return OS type", function() {
        // Given
        var mockWindow = {
          navigator: {
           userAgent: "Mozilla/5.0 (iPhone; CPU iPhone OS 9_0 like Mac OS X) AppleWebKit/601.1.46 (KHTML, like Gecko) Mobile/13A452 Safari Line/5.4.0"
          }
        };
        // When
        var osTypo = agent(mockWindow);
        // Then
        expect(osTypo).toEqual('ios');
    });
});

그 외 Front-End 테스트 관련 라이브러리

알고는 있자...

• Test Runner : 브라우저별 테스트를 실행하는 역할
  Karma
• Coverage : 코드 커버리지 리포트
  istanbul, isparta
• E2E Test : 서버와 클라이언트 간의 테스트. 즉, UI테스트 Selunium, Nightwatch.js, Phantomjs, Casperjs

Q1. 모든 상황에서
테스트 코드를 작성해야하는가?

테스트 코드가 많아진다.

= 소스의 코드가 많아진다.

= 변경시 비용이 많이 든다.

선별해서 작성하는게 현실적으로 좋다

주요 로직의 테스트 코드

결산 로직, 공통 라이브러리...

버그가 발생한 상황에 대한 테스트 코드

회기 테스트를 위한 테스트 코드 작성

전체 큰틀이 변경되지 않는 코드

• 솔루션 or 라이브러리
• 자주 변경되는 부분의 테스트를 만들게 되면 오히려 독이 될 수 있다.

Q2. 우리의 목표는 테스트 커버리지

테스트 커버리지가 100% 이다.

신뢰 할 수 있는가?

테스트 커버리지는 그냥 숫자일뿐.

테스트 커버리지 보다,

X-Driven 방식의 개발 프로세스가 잘되고 있는지

회기 테스트가 잘되고 있는지
가 더 중요하다.

정리

• 왜 테스트가 필요할까요?

  테스트 코드는 하나의 서비스다

• 테스트를 위한 개발 프로세스 (TDD,BDD)
  Red - Green - Refactor
• 테스트 코드 작성 Given-When-Then
• 자주 사용하는 테스트 유형

감사합니다.

BY 손찬욱 / chanuk.son