TDD

TDD란 프로그래밍 도중 내린 결정과 그 결정에 대한 피드백 사이의 간격을 인지하고, 또한 이 간격을 통제할 수 있게 해주는 기술을 말한다.

테스트 주도 개발에서는 다음 두 가지 단순한 규칙만 따른다.

  • 오직 자동화된 테스트가 실패할 경우에만 새로운 코드를 작성한다.

  • 중복을 제거한다.

테스트 주도 개발의 간략한 과정은 다음과 같이 요약할 수 있다.

  1. 재빨리 테스트 하나 추가한다.

  2. 모든 테스트를 실행하고 새로 추가한 것이 실패하는지 확인한다.

  3. 코드를 조금 바꾼다.

  4. 모든 테스트를 실행하고 전부 성공하는지 확인한다.

  5. 리팩토링을 통해 중복을 제거한다.

이 과정을 거치면서 아래 내용들을 경험할 수 있을 것이다.

  • 각각의 테스트가 기능의 작은 증가분을 어떻게 커버하는지

  • 새 테스트를 돌아가게 하기 위해 얼마나 작고 못생긴 변화가 가능한지

  • 얼마나 자주 테스트를 실행하는지

  • 얼마나 수 없이 작은 단계를 통해 리팩토링이 되어가는지

의존성과 중복

스티브 프리만(Steve Freeman)은 테스트와 코드 간의 문제는 중복이 아니라 테스트와 코드 사이에 존재하는 의존성이라고 말했다. 즉, 코드나 테스트 중 한쪽을 수정하면 반드시 다른 한쪽도 수정해야만 한다는 것이다. 의존성은 소프트웨어 개발의 모든 부분에서 핵심적인 문제이다.

의존성이 문제 그 자체라면, 중복은 문제의 징후이다. 중복의 가장 흔한 예는 로직 중복이며, 중복된 로직을 하나로 합치는데는 객체를 이용하는 것이 제일 좋다.

문제 자체는 남겨둔 채로 징후만을 제거하면 프로그램에서는 의존성도 제거된다. 이게 바로 TDD의 "중복을 제거한다." 두번째 규칙이 존재하는 이유이며, 다음 테스트로 진행하기전에 중복을 제거함으로 오직 한기지의 코드 수정을 통해 다음 테스트도 통과되게 만들 가능성을 최대화 하는 것이다.

일반적인 TDD 주기

  1. 빨강 : 실패하는 작은 테스트를 작성

    • 테스트를 작성한다. 이때 올바른 답을 찾기 위해서 필요한 모든 요소를 포함시켜야한다.

  2. 초록: 빨리 테스트가 통과하게끔 작성. 이를 위해서 기존코드 복붙, 테스트만 통과하도록 특정 상수 반환 함수 구현 등과 같이 구현해도 된다.

    • 실행 가능하게 만든다. 최대한 초록 막대(테스트 통과)를 볼 수 있게 하는 것이 가장 중요하다.

    • 접근법

      1. 가짜로 구현하기 : 상수를 반환하게 만들고 진짜 코드를 얻을 때까지 단계적으로 상수를 변수로 바꾼다.

      2. 삼각측량법(5 == 5, 5 != 6) : 어떻게 테스트를 구현해야할지 모를 때 작성

      3. 명백한 구현 사용하기 : 실제 구현을 입력한다.

  3. 리팩토링 : 일단 테스트를 통과하게만 하는 와중에 생겨난 모든 중복 제거

    • 올바르게 구현한다. 이때 중복을 제거하고, 테스트를 통과하기 위해 막 개발했던 코드를 수정한다.

3A 패턴

테스트 작성시 공통된 패턴을 발견하게 된다.

  1. 준비(arrange) : 객체 생성

  2. 행동(act) : 어떤 자극을 준다.

  3. 확인(assert) : 결과를 검사한다.

행동과 확인 단계는 매번 다르지만 준비 단계는 여러 테스트가 동일한 경우가 있다.

테스트를 위해서 새로운 객체를 얼마나 자주 생성해야될까?

이때 두가지 제약이 상충한다.

  • 성능 : 여러 테스트에서 같은 객체를 사용한다면, 객체 하나만 생성해 모든 테스트가 이 객체를 사용하도록 한다.

  • 격리 : 하나의 테스트에서 성공/실패가 다른 테스트에 영향을 주지 않기를 원한다. 테스트 객체를 공유하는 상태에서는 한개의 테스트의 결과가 다른 테스트의 결과에 영향을 미칠 확률이 높다.

테스트 사이의 커플링은 확실히 지저분한 결과를 만들며, 한 개의 테스트 결과가 다른 테스트 결과에 영향을 미칠 수도 있다. 그러므로 테스트 커플링은 만들면 안된다.

테스트를 격리하기 위해서는 결과적으로 시스템이 응집도는 높고 결합도는 낮은 객체의 모음으로 구성되게 해야한다.

테스트 주도 개발 패턴

테스트 우선

  • 테스트는 테스트목록을 모두 작성한 뒤 구현하자.

    1. 구현할 필요가 있는 모든 오퍼레이션의 사용 예를 작성

    2. 존재하지 않는 오퍼레이션에 대해서는 null버전을 리스트에 추가

    3. 리팩토링 목록추가

  • 테스트는 테스트 대상이 되는 코드를 구현하기 직전에 작성하는 것이 좋다.

단언(Assert) 우선

테스트 작성시 단언을 제일 먼저 쓰고 시작하자.

  1. 완료된 시스템이 어떨지에 대한 내용부터 작성

  2. 기능이 완료되면 통과할 수 있는 테스트 부터 작성

  3. 완료될 때 통과해야 할 단언부터 작성

테스트 데이터

테스트 데이터는 테스트를 읽을 때 쉽고 따라가기 좋은 데이터를 사용해야한다. 테스트 데이터에 대한 대안은 실제 데이터를 사용하는 것이다.

  • 실제 실행을 통해 외부 이벤트 결과를 이용하여 실시간 시스템을 테스트 하는 경우

  • 이전 시스템의 출력과 현재 시스템의 출력을 비교하고자 하는 경우 (병렬)

  • 시뮬레이션 시스템을 리팩토링한 후 기존과 정확히 동일한 결과가 나오는지 확인하고자 할 경우

위의 경우에 실제 데이터를 사용하면 유용하다.

명백한 데이터

테스트의 의도를 표현하기 위해서 테스트 자체에 예상되는 값과 실제 값을 포함하고, 둘 사이의 관계를 나타내야한다.

다른 통화로 환전하는데 있어서 수수료가 1.5%가 붙는다. USD에서 GBP로 교환하는 환율이 2:1이라면 $100달러를 환전하려면 50GBP - 1.5% = 49.25GBP여야한다.

Bank bank = new Bank();
bank.addRate("USD", "GBP", STANDARD_RATE);
bank.commission(STANDARD_COMMISSION);
Money result = bank.convert(new Note(100, "USD"), "GBP");
assertEquals(new Note(49.25, "GBP"), result);

계산을 더 명확히 표현하면 다음과 같다. 위의 예제 보다도 계산을 더 명확히 기입하면 테스트에서 입력으로 사용된 숫자와 결과 사이의 관계를 읽어낼 수 있으며, 다음으로 할 일을 더 쉽게 알 ㅅ ㅜ있다.

Bank bank = new Bank();
bank.addRate("USD", "GBP", 2);
bank.commission(0.015);
Money result = bank.convert(new Note(100, "USD"), "GBP");
assertEquals(new Note(100/2*(1-0.015), "GBP"), result);

아는 것에서 모르는 것으로

작성한 테스트 목록 중에서 아는 것부터 모르는 것으로 테스트 하는 것이 좋다.

뭘 구현해야될지 알면, 명백한 구현을 하고, 잘 모르겠다면 가짜 구현을 하면 된다.

모의 객체

모의 객체(Mock Object)를 사용하여 테스트시 실제 객체와 동일한 모의 객체를 만들어 테스트 효용성을 높이기 위해 사용한다.

모의 객체(Mock Object)란 주로 객체 지향 프로그래밍으로 개발한 프로그램을 테스트 할 경우 테스트를 수행할 모듈과 연결되는 외부의 다른 서비스나 모듈들을 실제 사용하는 모듈을 사용하지 않고 실제의 모듈을 "흉내"내는 "가짜" 모듈을 작성하여 테스트의 효용성을 높이는데 사용하는 객체이다.

위키 백과-모의 객체

모의 객체는 모든 객체의 가시성에 대해 고려하도록 만들어, 설계에서 커플링이 감소하도록 한다.

Code Coverage

코드 커버리지(Code Coverage)는 소프트웨어의 테스트를 논할 때 얼마나 테스트가 충분한가를 나타내는 지표중 하나다. 말 그대로 코드가 얼마나 커버되었는가이다. 소프트웨어 테스트를 진행했을 때 코드 자체가 얼마나 실행되었냐는 것이다.

코드의 구조를 이루는 것은 크게 구문(Statement), 조건(Condition), 결정(Decision)이다. 이러한 구조를 얼마나 커버했느냐에 따라 코드커버리지의 측정기준은 나뉘게 된다. 일반적으로 많이 사용되는 커버리지는 구문(Statement)커버리지이며, 실행 코드라인이 한번 이상 실행 되면 충족된다. 조건(Condition)커버리지는 각 내부 조건이 참 혹은 거짓을 가지면 충족된다. 결정(Decision) 커버리지는 각 분기의 내부 조건자체가 아닌 이러한 조건으로 인해 전체 결과가 참 혹은 거짓이면 충족된다. 그리고 조건과 결정을 복합적으로 고려하는 MC/DC 커버리지 또한 있다. - 위키백과 코드 커버리지

측정 기준

코드 커버리지는 소스 코드를 기반으로 수행하는 화이트 박스 테스트를 통해 측정한다.

화이트 박스 테스트(White-box test)

  • 응용 프로그램의 내부 구조와 동작을 검사하는 테스트 방식

  • 소프트웨어 내부 소스 코드를 테스트하는 기법

  • 개발자 관점의 단위 테스트 방법

구문(Statement)

구문 커버리지는 라인(Line) 커버리지라고 부르기도 하며, 코드 한 줄이 한 번 이상 실행되면 충족한다.

    void statement(int x) {
        System.out.println("start line"); // (1)
        if (x > 0) { // (2)
            System.out.println("middle line"); // (3)
        }
        System.out.println("last line"); // (4)
    }

여기서 x = -1 로 테스트를 진행하게 되면 (3)코드는 실행되지 않는다. 총 4개의 라인 중 1, 2, 4만 수행되므로 75%가 된다.

구문 커버리지가 가장 대표적으로 많이 사용되고 있다.

조건(Condition)

모든 조건식의 내부 조건이 true/false를 가지면 충족한다.

	void condition(int x, int y) {
        System.out.println("start line"); // (1)
        if (x > 0 && y < 0) { // (2)
            System.out.println("middle line"); // (3)
        }
        System.out.println("last line"); // (4)
    }

조건 커버리지를 만족하는 테스트 케이스는 x = 1, y = 1, x = -1, y = -1 이 있다.

  • x > 0 조건 : true/false

  • y < 0 조건 : false/true

조건 커버리지는 만족하지만 if문 조건은 항상 false이므로 (3) 코드는 실행되지 않는다.

조건 커버리지를 기준으로 테스트한 경우, 구문 커버리지와 결정 커버리지를 만족하지 못하는 경우가 존재할 수 있다.

결정(Decision)

결정 커버리지는 브랜치(Branch) 커버리지라고도 하며, 모든 조건식이 true/false를 가지게 되면 충족한다.

	void condition(int x, int y) {
        System.out.println("start line"); // (1)
        if (x > 0 && y < 0) { // (2)
            System.out.println("middle line"); // (3)
        }
        System.out.println("last line"); // (4)
    }

결정 커버리지를 만족하는 테스트 케이스는 x = 1, y = -1, x = -1, y = 1 이 있다.

  • x > 0, y < 0 모두 만족 : true

  • x > 0, y < 0 불충족 : false

조건/결정 커버리지는 코드 실행에 대한 테스트보다 로직 시나리오에 대한 테스트에 더 가깝다고 볼 수 있으며, 두 커버리지는 조건에 대해 모두 만족하면 코드 커버리지를 만족한다고 본다. 또한 조건문이 존재하지 않는 코드의 경우 두 커버리지 대상에서 아예 테스트 대상에서 제외 된다.

코드 커버리지 도구와 소나큐브(SonarQube) 정적 코드 분석 도구를 함께 사용해 코드 커버리지가 기존보다 떨어지는 경우 커밋이 불가능하도록 제한하기도 한다.

참고

Previous개발 방법론NextSpring

Last updated