3.5 테스트 자동화와 Mocha

컬러·2021년 1월 28일

JavaScript

목록 보기

24/27

테스트 자동화는 앞으로 풀어야 할 과제에서뿐만 아니라 현업에서도 광범위하게 쓰인다.

테스트는 왜 해야 하는가?

함수를 하나 만들고 있다고 해 보자. 대부분 매개변수-결과 관꼐를 중심으로 어떻게 코드를 작성할지 구상할 것이다.

개발 중엔 콘솔 창 등을 이용해 실제 실행 결과가 기대했던 결과와 같은지 계속 비교하면서 원하는 기능이 잘 구현되고 있는지 확인할 것이다.

실제 실행 결과가 기대했던 결과와 다를 땐, 코드를 수정하고 다시 실행해 그 결과를 기대했던 결과와 다시 비교해 볼 것이다. 원하는 기능을 완성할 때까지 이 과정을 계속 반복해야 한다.

그런데 이렇게 수동으로 코드를 '재실행'하는 건 상당히 불완전하다.

코드를 수동으로 '재실행'하면서 테스트를 하면 무언가를 놓치기 쉽다.

구체적인 예를 들어보자. 현재 함수 f를 구현하고 있다고 가정해보겠다. 코드를 작성하고 f(1)이 제대로 동작하는지 확인한다. 제대로 동작한다. 그런데 f(2)를 테스트해 보니 제대로 동작하지 않는다. 코드를 수정한 후 다시 f(2)를 확인해보자. 제대로 동작한다. 여기서 끝일까? 아니다. f(1)이 제대로 동작하는지 확인하지 않았으니까. 이렇게 테스트를 수동으로 하면 에러가 발생할 여지를 남긴다.

이런 일은 아주 흔한 발생한다. 개발자는 무언가를 만들 때 머릿속에 수많은 유스 케이스를 생각하고 코드를 작성하는데, 코드를 변경해야 할 떄마다 모든 유스 케이스를 상기하면서 코드를 수정하는 것은 거의 불가능하다. 하나를 고치면 또 다른 문제가 튀어나오는 이유가 바로 이 때문이다.

Behavior Driven Development

Behavior Driven Development(BDD) 라 불리는 방법론에 대해 알아보자.

BDD는 테스트(test), 문서(documentaion), 예시(example)를 한데 모아놓은 개념이다.

실제 개발 사례를 이용해 BDD가 무엇인지 차근차근 설명해 보도록 하겠다.

거듭제곱 함수와 명세서

x를 n번 곱해주는 함수, pow(x, n)를 구현하고 있다고 가정해 보자.(단, n은 자연수이고, 조건 n≥0을 만족해야 한다.)

사실 자바스크립트엔 거듭제곱 연산자 **가 있다. 그럼에도 불구하고 함수를 직접 구현하는 이유는, 구현 과정에 초점을 두면서 BDD를 직접 적용해 보기 위해서이다. 기능이 간단한 함수를 구현하면서 BDD를 직접 적용해 보면 큰 문제에 BDD를 적용하는 건 쉬울 테니까 말이다.

본격적으로 코드를 작성하기 하기 전에 먼저 해야 할 것이 있다. 코드가 무슨 일을 하는지 상상한 후 이를 자연어로 표현해야 한다.

이때, 만들어진 산출물을 BDD에선 명세서(specification) 또는 짧게 줄여 스펙(spec) 이라고 부른다. 명세서엔 아래와 같은 유스 케이스에 대한 자세한 설명과 테스트가 담겨있다.

describe("pow", function() {

  it("주어진 숫자의 n 제곱", function() {
    assert.equal(pow(2, 3), 8);
  });

});

스펙은 세 가지 주요 구성 요소로 이루어진다.
describe("title", function() {...})
구현하고자 하는 기능에 대한 설명이 들어간다. 우리 예시에선 함수 pow가 어떤 동작을 하는지에 대한 설명이 들어갈 것이다. it 블록을 한데 모아주는 역할도 한다.

it("유스 케이스 설명, function()
it의 첫 번째 인수엔 특정 유스 케이스에 대한 설명이 들어간다. 이 설명은 누구나 읽을 수 있고 이해할 수 있는 자연어 로 적어준다. 두 번째 인수엔 유스 케이스 테스트 함수가 들어간다.

assert.equal(value1. value2)
기능을 제대로 구현했다면 it 블록 내의 코드 aseert.equal(value1, value2) 이 에러 없이 실행된다.

함수 assert.*는 pow가 예상한 대로 동작하는지 확인해준다. 위 예시에선 aseert.equal이 사용되었는데, 이 함수는 인수끼리 동등 비교했을 때 다르다고 판단되면 에러를 반환한다. 예시에선 pow(2, 3) 의 결괏값과 8을 비교한다. 비교나 확인에 쓰이는 다른 함수들은 아래에서 다시 소개하겠다.

명세서는 실행 가능하다. 명세서를 실행하면 it 블록 안에 테스트가 실행된다. 자세한 내용은 아래에서 다시 설명하겠다.

개발 순서

실제 개발에 착수하면 아래와 같은 순서로 개발이 진행된다.

명세서 초안을 작성한다. 초안엔 기본적인 테스트도 들어간다.
명세서 초안을 보고 코드를 작성한다.
코드가 작동하는지 확인하기 위해 Mocha 라 불리는 테스트 프레임워크를 사용해 명세서를 실행한다. 이때, 코드가 잘못 작성되었다면 에러가 출력된다. 개발자는 테스트를 모두 통과해 에러가 더는 출력되지 않을 때까지 코드를 수정한다.
모든 테스트를 통과하는 코드 초안이 완성되었다.
명세서에서 지금까진 고려하지 않았던 유스케이스 몇 가지를 추가한다. 테스트가 실패하기 시작할 것이다.
세 번재 단계로 돌아가 테스트를 모두 통과할 때까지 코드를 수정한다.
기능이 완성될 때까지 3~6단꼐를 반복한다.

위와 같은 방법은 반복적인(iterative) 성격을 지닌다. 명세서를 작성하고 실행한 후 테스트를 모두 통과할 때까지 코드를 작성하고, 또 다른 테스트를 추가해 앞의 과정을 반복하니까 말이다. 이렇게 하다 보면 종래에는 완전히 동작하는 코드와 테스트 둘 다를 확보하게 된다.

이제 실제 사례에 위 개발 프로세르를 적용해 보겠다.

함수 pow의 스펙 초안은 이미 위에서 작성했으므로, 첫 번째 단계를 이미 끝난 상황이다. 코드를 본격적으로 작성하기 전에 잠시 자바스크립트 라이브러리 몇 가지를 사용해 테스트를 싱행해 보겠다. 지금 상태에선 테스트 모두가 실패할 텐데 그런데도 실행해 보는 이유는 테스트가 실제로 돌아가는지 확인하기 위해서이다.

스펙 실행하기

3개의 라이브러리에 대해서 알아보자. 라이브러리에 대한 설명은 다음과 같다.

Mocha - 핵심 테스트 프레임워크로, describe, it과 같은 테스팅 함수와 테스트 실행 관련 주요 함수를 제공
Chai - 다양한 assertion을 제공해 주는 라이브러리. 우리 예시에선 assert.equal 정도만 사용해 볼 예정이다.
Sinon - 함수의 정보를 캐내는 데 사용되는 라이브러리. 내장 함수 등을 모방한다. 본 챕터에서는 사용하지 않고, 다른 챕터에서 실제로 사용해 볼 예정이다.

세 라이브러리 모두, 브라우저나 서버 사이드 환경을 가리지 않고 사용 가능하다. 여기선 브라우저 환경을 가정하고 사용해 보겠다.
아래 HTML 페이지엔 pow의 스펙, 라이브러리 모두가 들어있다.

<!DOCTYPE html>
<html>
<head>
  <!-- 결과 출력에 사용되는 mocha css를 불러옵니다. -->
  <link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/mocha/3.2.0/mocha.css">
  <!-- Mocha 프레임워크 코드를 불러옵니다. -->
  <script src="https://cdnjs.cloudflare.com/ajax/libs/mocha/3.2.0/mocha.js"></script>
  <script>
    mocha.setup('bdd'); // 기본 셋업
  </script>
  <!-- chai를 불러옵니다 -->
  <script src="https://cdnjs.cloudflare.com/ajax/libs/chai/3.5.0/chai.js"></script>
  <script>
    // chai의 다양한 기능 중, assert를 전역에 선언합니다.
    let assert = chai.assert;
  </script>
</head>

<body>

  <script>
    function pow(x, n) {
      /* 코드를 여기에 작성합니다. 지금은 빈칸으로 남겨두었습니다. */
    }
  </script>

  <!-- 테스트(describe, it...)가 있는 스크립트를 불러옵니다. -->
  <script src="test.js"></script>

  <!-- 테스트 결과를 id가 "mocha"인 요소에 출력하도록 합니다.-->
  <div id="mocha"></div>

  <!-- 테스트를 실행합니다! -->
  <script>
    mocha.run();
  </script>
</body>

</html>

위 페이지는 다섯 부분으로 나눌 수 있다.

<head> - 테스트에 필요한 서드파티 라이브러리와 스타일을 불러옴.
<script> - 테스트할 함수(pow)의 코드가 들어감
테스트 - desrive("pow", ...)를 외부 스크립트(test.js)에서 불러옴.
HTML 요소 - <div id="mocha"> - Mocha 실행 결과가 출력됨
mocha.run() - 테스트를 실행시켜주는 명령어

코드 초안

오로지 테스트 통과만을 목적으로 코드를 간단하게 작성해보겠다.

function pow(x, n) {
  return 8; // 속임수를 써봤습니다. :)
}

스펙을 실행해도 에러가 발생하지 않는다.

스펙 개선하기

지금까진 꼼수를 써서 코드를 작성했기 때문에 pow(3, 4)를 실행하면 틀린 결과를 내뱉을 것이다. 하지만 테스트는 모두 통과한다.

이렇게 테스트는 모두 통과하지만, 함수가 제 역할을 하지 못하는 경우는 실무에서 빈번하게 발생한다. 스펙이 불완전해서 그런것이니 더 많은 유스 케이스를 추가해 보자.

pow(3, 4) = 81을 만족하는지 확인하는 테스트를 추가하겠다.

스펙에 테스트를 주가하는 방법은 아래와 같이 두 가지가 있다.

기존 it 블록에 aseert를 하나 더 추가하기

describe("pow", function() {

  it("주어진 숫자의 n 제곱", function() {
    assert.equal(pow(2, 3), 8);
    assert.equal(pow(3, 4), 81);
  });

});

테스트를 하나 더 추가하기(it 블록 하나 더 추가하기)

describe("pow", function() {

  it("2를 세 번 곱하면 8입니다.", function() {
    assert.equal(pow(2, 3), 8);
  });

  it("3을 네 번 곱하면 81입니다.", function() {
    assert.equal(pow(3, 4), 81);
  });

});

assert에서 에러가 발생하면 it 블록은 즉시 종료된다. 따라서 it 블록에 assert를 하나 더 추가하면 첫 번째 assert가 실패했을 때 두 번째 assert 의 결과를 알 수 없다. 두 방법의 근본적인 차이는 여기에 있다.

두 번째 방법처럼 it 블록을 하나 더 추가해 테스트를 분리해서 작성하면 더 많은 정보를 얻을 수 있기 때문에 두 번째 방법을 추천한다.

여기에 더하여 테스트를 추가할 땐 다음 규칙도 따르는 게 좋다.

테스트 하나에선 한 가지만 확인하기
테스트 하나에 연관이 없는 사항 두 개를 점검하고 있다면, 이 둘을 분리하는 게 좋다.

코드 개선하기

두 번째 테스트도 통과할 수 있게 코드를 개선해 보자. 이번엔 꼼수를 쓰지 말고 실제 우리가 구현하고자 했던 기능을 생각하면서 코드를 작성하자.

function pow(x, n) {
  let result = 1;

  for (let i = 0; i < n; i++) {
    result *= x;
  }

  return result;
}

함수가 제대로 작동하는지 확인하기 위해 더 많은 값을 테스트해 보자. 수동으로 여러 개의 it 블록을 만드는 대신 for 문을 사용해 자동으로 it 블록을 만들어보겠다.

describe("pow", function() {

  function makeTest(x) {
    let expected = x * x * x;
    it(`${x}을/를 세 번 곱하면 ${expected}입니다.`, function() {
      assert.equal(pow(x, 3), expected);
    });
  }

  for (let x = 1; x <= 5; x++) {
    makeTest(x);
  }

});

중첩 describe

테스트를 몇 개 더 추가해 보겠다. 아래 예시에서 헬퍼 함수 makTest와 for 문이 중첩 describe 안에 함께 묶여있다는 것을 눈여겨보길 바란다. makeTest는 오직 for 문에서만 사용되고, 다른 데선 사용되지 않기 때문에 이렇게 묶어놓았다.

아래 스펙에서 makeTest 와 for 문은 함께 어우러져 pow 가 제대로 동작하는지 확인해주는 역할을 한다.

이렇게 중첩 describe 를 쓰면 그룹을 만들 수 있다.

describe("pow", function() {

  describe("x를 세 번 곱합니다.", function() {

    function makeTest(x) {
      let expected = x * x * x;
      it(`${x}을/를 세 번 곱하면 ${expected}입니다.`, function() {
        assert.equal(pow(x, 3), expected);
      });
    }

    for (let x = 1; x <= 5; x++) {
      makeTest(x);
    }

  });

  // describe와 it을 사용해 이 아래에 더 많은 테스트를 추가할 수 있습니다.
});

중첩 describe 는 새로운 테스트 '하위 그룹(subgroup)'을 정의할 때 사용된다. 이렇게 새로 정의된 테스트 하위 그룹은 테스트 결과 보고서에 들여쓰기 된 상태로 출력된다.

✔ `before/after` 와 `beforeEach/afterEach`

함수 before는 (전체) 테스트가 실행되기 전에 실행되고, 함수 after는 (전체) 테스트가 실행된 후에 실행된다. 함수 beforeEach는 메it이 실행되기 전에 실행되고, 함수 agterEach 는 메 it이 실행된 후에 실행된다.

예)

describe("test", function() {

  before(() => alert("테스트를 시작합니다 - 테스트가 시작되기 전"));
  after(() => alert("테스트를 종료합니다 - 테스트가 종료된 후"));

  beforeEach(() => alert("단일 테스트를 시작합니다 - 각 테스트 시작 전"));
  afterEach(() => alert("단일 테스트를 종료합니다 - 각 테스트 종료 후"));

  it('test 1', () => alert(1));
  it('test 2', () => alert(2));

});

실행 순서는 다음과 같다.

테스트를 시작합니다 - 테스트가 시작되기 전          (before)
단일 테스트를 시작합니다 - 각 테스트 시작 전         (beforeEach)
1
단일 테스트를 종료합니다 - 각 테스트 종료 후         (afterEach)
단일 테스트를 시작합니다 - 각 테스트 시작 전         (beforeEach)
2
단일 테스트를 종료합니다 - 각 테스트 종료 후         (afterEach)
테스트를 종료합니다 - 테스트가 종료된 후            (after)

beforeEach/afterEach와 before/after는 대개 초기화 용도로 사용된다. 카운터 변수를 0으로 만들거나 테스트가 바뀔 때(또는 테스트 그룹이 바뀔 때)마다 해줘야 하는 작업이 있으면 이들을 이용할 수 있다.

스펙 확장하기

첫 번째 반복(iteration)에선 함수 pow 의 기본적인 기능을 구현해보았다. 그런데 아직 샴페인을 마시며 자축하긴 이르다. 또 다른 반복을 돌면서 기능을 개선해 보자.

앞서 정의했듯이 함수 pow(x, n) 의 매개변수 n은 양의 정수이어야 한다.

자바스크립트에선 수학 관련 연산을 수행하다 에러가 발생하면 NaN를 반환한다. 함수 pow 도 n이 조건에 맞지 않으면 naN을 반환해야 한다.

n이 조건에 맞지 않을 떄 함수가 NaN을 반환하는지 아닌지를 검사해주는 테스트를 추가해보겠다.

describe("pow", function() {

  // ...

  it("n이 음수일 때 결과는 NaN입니다.", function() {
    assert.isNaN(pow(2, -1));
  });

  it("n이 정수가 아닐 때 결과는 NaN입니다.", function() {
    assert.isNaN(pow(2, 1.5));
  });

});

기존엔 n이 음수이거나 정수가 아닌 경우를 생각하지 않고 구현했기 때문에, 새롭게 추가한 테스트는 실패할 수밖에 없다. BDD의 핵심은 여기에 있다. 실패할 수밖에 없는 테스트를 추가하고, 테스트를 통과할 수 있게(에러가 발생하지 않게) 코드를 개선하는 것이다.

✔ 다양한 assertion

위에서 사용한 assert.inNaN은 NaN인지 아닌지를 확인해준다.

Chai는 이 외에도 다양한 assertion을 지원한다.

assert.equal(value1, value2) - value 과 value2의 동등성을 확인.(value1 == value2)
assert.strictEqual(value1, value2) - value1과 value2 의 일치성을 확인.(value1 === value2)
assert.notEqual, assert.notStrictEqaul- 비 동등성, 비 일치성을 확인
assert.isTrue(value) - value가 true인지 확인.(value === true)
assert.isFalse(value) - value가 fasle인지 확인.(value === false)

새롭게 추가한 테스트를 통과할 수 있도록 pow에 코드를 몇 줄 추가

function pow(x, n) {
  if (n < 0) return NaN;
  if (Math.round(n) != n) return NaN;

  let result = 1;

  for (let i = 0; i < n; i++) {
    result *= x;
  }

  return result;
}

이제 에러 없이 테스트를 모두 통과함

요약 ✔

BDD에선 스펙을 먼저 작성하고 난 후에 구현을 시작한다. 구현이 종료된 시점에는 스펙과 코드 둘 다를 확보할 수 있다.

스펙의 용도는 세 가지이다.

테스트 -함수가 의도하는 동작을 제대로 수행하고 있는지를 보장함
문서 - 함수가 어떤 동작을 수행하고 잇는지 설명해줌. describe와 it에 설명이 들어감
예시 - 실제 동작하는 예시를 이용해 함수를 어떻게 사용할 수 있는지 알려줌

스펙이 있기 ㄷ대문에 개발자는 안전하게 함수를 개선하거나 변경할 수 있다. 함수를 처음부터 다시 작성해야 하는 경우가 생겨도 스펙이 있으면 기존 코드와 동일하게 동작한다는 것을 보장할 수 있다.

코드가 바뀌어도 기존에 구현된 기능에 영향을 주지 않게 하는 건 대규모 프로젝트에서 매우 중요하다. 프로젝트 규모가 커지면 함수 하나를 이곳저곳에서 사용하는데, 수동으로 변경된 함수가 이 함수를 사용하는 모든 곳에서 제대로 동작하는지 확인하는 건 불가능하기 때문이다.

테스트를 하지 않고 코드를 작성해왔다면 개발자들은 둘 중 한 갈래의 길에 빠져버리고 만다.

아무 대책 없이 코드를 변경한다. 부작용을 생각하지 않고 함수를 수정했기 ㄷ대문에 어디선가 버그가 발생하고 만다.
수정이나 개선을 기피하게 된다. 버그의 대가가 가혹하기 때문이다. 코드가 구식이 되어도 그 누구도 코드를 건드리려 하지 않는다. 좋지 않은 상황이다.

테스팅 자동화는 이런 문제를 피하게 도와준다!

테스팅 자동화를 수행하고 있는 프로젝트라면 이런 문제를 걱정하지 않아도 된다. 코드에 변화가 있어도 스펙을 실행해 테스트를 진행하면 몇 초 만에 에러 발생 여부를 확인할 수 있다.

장점이 하나 더 있다. 잘 테스트 된 코드는 더 나은 아키텍처를 만든다.

수정과 개선이 쉬우니까 당연히 좋은 아키텍처를 만들 수 있다고 생각할 수 있다. 하지만 또 다른 이유가 있다.

테스트를 작성하려면 함수가 어떤 동작을 하는지, 입력값은 무엇이고 출력값은 무엇인지 정의하고 난 후에 구현을 시작한다. 코드는 정의된 사항을 뒷받침 할 수 있게 작성해야 한다. 구현을 시작하는 순간부터 이미 좋은 아키텍처가 보장된다.

사실, 매번 이런 절차를 ㄷ다라 구현한다는 게 쉽지만은 않다. 함수가 어떻게 동작해야 하는지 확신이 서지 않는 상황에서 코드를 작성하기도 전에 스펙을 작성해야 하므로 익숙하지 않을 수 있다. 그렇지만 테스트를 작성하면 일반적으로 개발 속도가 빨라지고 이전보다 코드를 더 안정적으로 작성할 수 있다.

과제

잘못된 점 찾기

함수 pow의 테스트 코드를 보고 무엇이 잘못되었나 알아보자.

it("주어진 숫자의 n 제곱", function() {
  let x = 5;

  let result = x;
  assert.equal(pow(x, 1), result);

  result *= x;
  assert.equal(pow(x, 2), result);

  result *= x;
  assert.equal(pow(x, 3), result);
});

참고: 문법 오류는 없고, 모든 테스트가 문제없이 통과한다.

해답

테스트 함수가 하나뿐이기 때문에, 에러가 발생했을 ㄷ대 원인을 찾기가 힘들다.

실행의 흐름이 복잡한 경우 테스스 코드를 디버깅 해야 하는 상황이 생길 수 있다.
테스트는 명확한 입력값, 출력값과 함께 여러 개의 it 블록으로 쪼개 작성하는 것이 좋다.

describe("주어진 숫자의 n 제곱", function() {
  it("5를 1 제곱하면 5", function() {
    assert.equal(pow(5, 1), 5);
  });

  it("5를 2 제곱하면 25", function() {
    assert.equal(pow(5, 2), 25);
  });

  it("5를 3 제곱하면 125", function() {
    assert.equal(pow(5, 3), 125);
  });
});

여기에 더하여 위와 같이 it 블록을 여러 개로 쪼개면 it 대신 it.only를 사용해 원하는 테스트만 실행해 볼 수 있다.

describe("주어진 숫자의 n 제곱", function() {
  it("5를 1 제곱하면 5", function() {
    assert.equal(pow(5, 1), 5);
  });

  // Mocha는 아래 블록만 실행합니다.
  it.only("5를 2 제곱하면 25", function() {
    assert.equal(pow(5, 2), 25);
  });

  it("5를 3 제곱하면 125", function() {
    assert.equal(pow(5, 3), 125);
  });
});

컬러

이전 포스트

3.4 닌자 코드

다음 포스트

3.5 테스트 자동화와 Mocha

JavaScript

테스트는 왜 해야 하는가?

Behavior Driven Development

거듭제곱 함수와 명세서

개발 순서

스펙 실행하기

코드 초안

스펙 개선하기

코드 개선하기

중첩 describe

✔ `before/after` 와 `beforeEach/afterEach`

스펙 확장하기

✔ 다양한 assertion

요약 ✔

과제

잘못된 점 찾기

해답

3.4 닌자 코드

3.6 폴리필

0개의 댓글

3.5 테스트 자동화와 Mocha

JavaScript

테스트는 왜 해야 하는가?

Behavior Driven Development

거듭제곱 함수와 명세서

개발 순서

스펙 실행하기

코드 초안

스펙 개선하기

코드 개선하기

중첩 describe

✔ before/after 와 beforeEach/afterEach

스펙 확장하기

✔ 다양한 assertion

요약 ✔

과제

잘못된 점 찾기

해답

3.4 닌자 코드

3.6 폴리필

0개의 댓글

✔ `before/after` 와 `beforeEach/afterEach`