✔️ TDD | 테스트 주도 개발, 유닛 테스트(테스트 케이스)

 

Test-driven development

 

TDD를 설명하기 전에, 먼저 디버깅에 대해 알아야 한다. 디버깅은 쉽게 말해서 문제가 발생했을 때 그 문제를 해결해주는 도구이다. 🐛 버그를 잡는다는 의미로 문제의 원인을 잡을 수 있도록 도와준다. 

 

디버깅을 모른다면, 삽질을 하고도 원인을 파악하지 못할 것이다. 때문에 디버깅은 개발에서 떼어놓을 수 없는 스킬이다. 

 

 

sum 이라는 함수를 선언한 후, 실행했을 때 에러가 생기는 것을 알 수 있다. ❌ 버그가 잡힌 것이다. 

 

 

디버거로 확인을 하면 문제가 생긴 원인을 확인할 수 있다. "원인은 x표시가 난 곳이구나!" 그리고 console.lo가 function이 아니라는 것을 확인할 수 있다. 

 

이런 에러를 처음부터 줄일 수 있도록 도와주는 방법이 바로 TDD이다. TDD로 했을 때는 

 

  it("sum 함수는 인자값들을 더한 값을 리턴해야 합니다.", function(){
    let result = sum(1,2);
    expect(result).toEqual(3);
  })

 

요구사항으로 위에 코드처럼 '만약 1,2를 sum이라는 함수에 인자값으로 주었을 때, result가 3이길 바란다' 라고 작성할 수 있다. 그리고 실제 테스트를 돌리면서 기댓값과 실제값을 비교하면서 코드를 확인할 수 있다. 

 

그리고 더 많은 경우의 수를 가지고 테스트를 추가할 수 있다. 

 

📌  유닛테스트

위의 예시처럼 경우의 수를 정리하고, 경우의 수에 대해 하나씩 기댓값과 실제값을 비교하는 것을 유닛 테스트라고 부르고, 이러한 개발 방법론을 테스트 주도 개발이라고 부른다.  

 

유닛은 각각 하나의 함수, 하나의 컴포넌트를 뜻한다. 유닛테스트 해야할 것은 이 각각의 함수들이 자신의 역할을 약속한대로 하고 있는지 검증해주는 것이다. 

 

📌  TDD 

Test-driven Development의 약자로 테스트를 코드보다 먼저 작성하는 방법론이다. 작성한 테스트의 요구사항을 가이드라인처럼 따르면서 코드를 작성해나가는 방식이다.  

 

이미 테스트 코드를 작성한다는 것 자체가, 고민이 필요한 부분이다. 어떤것이 바람직한 코드이고, 어떻게 작성할 예정인지에 대한 구상이 끝났을 때 테스크 코드를 작성할 수 있다. 그래서 TDD로 하지 않았을 때보다 시간이 더 걸린다는 단점이 있지만, 결과적으로 봤을 때는 미리 코드의 구조를 짜기(Design) 때문에 나중에 버그가 생길 가능성을 낮춰 오히려 시간을 더 아낄 수 있을 것이다.

 

📌  TDD를 하는 이유

프로젝트를 진행하면서 TDD를 할 겨를도 없었고, TDD를 왜 해야 하는지 몰랐다. 하지만 프로젝트의 거의 끝에 가서 TDD의 중요성을 깨달았다. test를 진행하지 않고 무작정 코드를 짜다보니 코드를 구성하는데 시간이 많이 걸렸고, 버그가 많이 생겼다. 그리고 버그를 찾는 것 자체가 어려웠었던 것 같다. 

 

하지만 TDD로 프로젝트를 진행했었다면 미리 코드의 구조를 짤 수 있어 협업을 하는 데도 더 편리했을 것이고, 에러를 찾기 수월했을 것이고, 왜 에러가 났는지 원인을 알 수 있었을 것이고, 좀 더 정돈된 코드를 짤 수 있었을 것이다. 또, 나의 코드가 내가 예상했던 대로 돌아갈 것이라는 확신이 있었을 것이다.

 

협업을 진행하는데 있어서도 TDD는 정말 중요한 스킬이라는 생각이 든다.

 

이처럼 TDD는 테스트가 가이드 역할을 해준다. 버그의 발생 가능성을 줄여주고, 테스트 자체가 요구사항을 분명하게 드러내기 때문에 코드도 역할에 맞게 분명하게 짤 수 있다. (SimpleDesign) 

 

📌 TDD 실전

1. 경우의 수를 찾고, 경우의 수에 대하여 하나씩 기댓값을 테스트로 작성한다. 

2. 테스트를 통과시킨다. 

3. 코드를 더 바람직하게 재구성한다.(refactor)

4. 다시 유닛 테스트를 작성한다. 

 

TDD는 이 과정을 계속 반복하면서 이루어진다. 시간이 꽤 오래걸리겠지만 확실히 퀄리티 높은 코드를 짤 수 있다.

 

Test Framework

※ 프레임워크 : 뼈대, 기반구조

※ 라이브러리 : 단순 활용가능한 도구들의 집합

 

 

유닛 테스트를 도와주는 것이 테스트 프레임워크이다. 여러 개발자들이 TDD를 더 잘할 수 있도록 모여서 많은 테스트 오픈소스 프레임 워크를 제작했다.

 

나는 mocha, chai를 사용해보았는데, 그 외에도 jest, supertest,jasmine 등 굉장히 많은 프레임 워크가 존재한다. 

 

 

📌 Mocha 

모카는 Node.js 프로그램 용 JavaScript 테스트 프레임 워크이다. 테스트 프레임 워크는 내장 기능이 아니기 때문에 따로 설치를 해주어야한다. 그리고 개발환경에서만 사용하기 때문에 devDependencies 설정을 해주어야 한다. 

  $ npm install -g mocha --save-dev

 

설치가 끝났다면 아래의 코드처럼 테스트 코드를 작성한다.

  describe("sum", function() {
  let assert = function(isTrue) {
    if (!isTrue) {
      throw new Error("Test failed");
    }
  };

  it("1과 2를 넣었을 때, 3이 나와야한다.", function() {
    assert(sum(1,2) === 3);
  });

  it("2와 10을 넣었을 때, 12가 나와야한다.", function() {
    assert(sum(2,10) === 12);
  });
});

1. describe("title", function(){...})

구현 기능에 대한 설명이 들어간다. it 블록들을 하나로 모아주는 설명이다. 

 

2. it("케이스 설명",  function(){...})

이해하기 쉬운 케이스 설명을 적어주고, 테스트 함수를 넣어주면 된다. 

 

 

chai는 assert라는 함수를 직접 정의할 필요 없이 assertion을 제공해주는 라이브러리이다. 

 

 

 

유닛 테스트 vs 통합 테스트 vs 기능 테스트

 

👉 유닛 테스트(unit test) 

복잡도  | 어려움 ⭐⭐

유닛 테스트란 단위 테스트이다. 각각의 함수나 컴포넌트가 독립적으로 잘 동작하고 있는지 테스트하는 것이다.

 

👉 통합 테스트(Integration test)

복잡도 | 어려움 ⭐⭐⭐

테스트는 각각의 모듈들이 잘 연계되어서 작동하는지 테스트하는 것이다. 

 

👉 기능 테스트(functional test)

복잡도 | 어려움 ⭐⭐⭐⭐⭐

기능 테스트는 하나의 어플리케이션이 잘 작동하는지 완전한 기능을 테스트하는 것이다. (유저와 상호작용 테스트시)

 

 

 

 

 

[관련도서] 

 

 

 

 

 

[참고자료] ko.javascript.info/testing-mocha

테스트 자동화와 Mocha

www.youtube.com/watch?v=oneGCBiPK_Q