TDD (테스트 주도 개발)

테스트 주도 개발이란?

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

테스트 주도 개발에서는 아래 두 가지 단순한 규칙만을 따릅니다.

1. 오직 자동화된 테스트가 실패할 경우에만 새로운 코드를 작성한다.
2. 중복을 제거한다.

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

1. 빠르게 테스트 하나 추가한다.
2. 모든 테스트를 실행하고 새로 추가한 것이 실패하는지 확인한다.
3. 코드를 조금 바꾼다.
4. 모든 테스트를 실행하고 전부 성공하는지 확인한다.
5. 리팩토링을 통해 중복을 제거한다.

이 과정을 수행하면서

• 각각의 테스트가 기능의 작은 증가분을 어떻게 커버하는지
• 새 테스트를 돌아가게 하기 위해 얼마나 작고 못생긴 변화가 가능한지
• 얼마나 자주 테스트를 실행하는지
• 얼마나 수없이 작은 단계를 통해 리팩토링이 되어가는지
  에 대한 부분을 경험할 수 있습니다.

의존성과 중복

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

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

일반적인 TDD Cycle

1. 빨강 : 실패하는 작은 테스트를 작성
   • 테스트를 작성한다. 이때 올바른 답을 찾기 위해서 필요한 모든 요소를 포함해야 함
2. 초록: 빨리 테스트가 통과하게끔 작성. 이를 위해서 기존 코드 복사/붙여넣기, 테스트만 통과하도록 특정 상수 반환 함수 구현 등과 같이 구현해도 됩니다.
   • 실행할 수 있게 만든다. 최대한 초록 막대(테스트 통과)를 볼 수 있게 하는 것이 가장 중요하다.
   • 접근법
     1. 가짜로 구현하기 : 상수를 반환하게 만들고 진짜 코드를 얻을 때까지 단계적으로 상수를 변수로 바꾼다.
     2. 삼각측량법(5 == 5, 5 != 6) : 어떻게 테스트를 구현해야 할지 모를 때 작성
     3. 명백한 구현 사용하기 : 실제 구현을 입력한다.
3. 리팩토링 : 일단 테스트를 통과하게만 하는 와중에 생겨난 모든 중복 제거
   • 올바르게 구현한다. 이때 중복을 제거하고, 테스트를 통과하기 위해 막 개발했던 코드를 수정한다.

3A 패턴

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

1. 준비(arrange)
2. 행동(act)
3. 확인(assert)

행동과 확인 단계는 매번 다르지만, 준비 단계는 여러 테스트가 동일한 경우가 있습니다.
테스트를 위해서 새로운 객체를 얼마나 자주 생성해야 할까요?
이때 두 가지 제약이 서로 상충하게 됩니다.

• 성능 : 여러 테스트에서 같은 객체를 사용한다면, 객체 하나만 생성해 모든 테스트가 이 객체를 사용하도록 한다.
• 격리 : 하나의 테스트에서 성공/실패가 다른 테스트에 영향을 주지 않기를 원한다. 테스트 객체를 공유하는 상태에서는 한 개의 테스트의 결과가 다른 테스트의 결과에 영향을 미칠 확률이 높다.

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

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

테스트 주도 개발 패턴

테스트 우선

테스트는 테스트 목록을 모두 작성한 뒤 구현합니다.
테스트는 테스트 대상이 되는 코드를 구현하기 직전에 작성하는 것이 좋습니다.

단언(Assert) 우선

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

1. 완료된 시스템이 어떨지에 대한 내용부터 작성
2. 기능이 완료되면 통과할 수 있는 테스트부터 작성
3. 완료될 때 통과해야 할 단언부터 작성

테스트 데이터

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

• 실제 실행을 통해 외부 이벤트 결과를 이용하여 실시간 시스템을 테스트하는 경우
• 이전 시스템의 출력과 현재 시스템의 출력을 비교하고자 하는 경우 (병렬)
• 시뮬레이션 시스템을 리팩토링한 후 기존과 정확히 동일한 결과가 나오는지 확인하고자 할 경우

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

명백한 데이터

테스트의 의도를 표현하기 위해서 테스트 자체에 예상되는 값과 실제 값을 포함하고, 둘 사이의 관계를 나타내야 합니다.
더 명확히 기입하면 테스트에서 입력값과 결과 사이의 관계를 읽어낼 수 있으며, 다음으로 할 일을 더 쉽게 알 수 있습니다.

아는 것에서 모르는 것으로

작성한 테스트 목록 중에서 아는 것부터 모르는 것으로 테스트하는 것이 좋습니다.
뭘 구현해야 할지 알면, 명백한 구현을 하고, 잘 모르겠다면 가짜 구현을 하면 됩니다.

모의 객체

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

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

위키 백과-모의 객체

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

Code Coverage

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

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

측정 기준

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

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

• 응용 프로그램의 내부 구조와 동작을 검사하는 테스트 방식
• 소프트웨어 내부 소스 코드를 테스트하는 기법
• 개발자 관점의 단위 테스트 방법

구문(Statement)

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

    fun statement(x: Int) {
        println("start") // (1)
        if (x > 0) { // (2)
            println("middle") // (3)
        }
        println("last") // (4)
    }

여기서 x = -1 로 테스트를 진행하게 되면 (3)코드는 실행되지 않으며, 총 4개의 라인 중 1, 2, 4만 수행되므로 75%가 됩니다.
구문 커버리지가 가장 대표적으로 많이 사용되고 있습니다.

조건(Condition)

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

    fun condition(x: Int, y: Int) {
        println("start") // (1)
        if (x > 0 && y < 0) { // (2)
            println("middle") // (3)
        }
        println("last") // (4)
    }

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

• x > 0 조건 : true/false
• y < 0 조건 : false/true

조건 커버리지는 만족하지만 if문 조건은 항상 false이므로 (3) 코드는 실행되지 않습니다.
조건 커버리지를 기준으로 테스트한 경우, 구문 커버리지와 결정 커버리지를 만족하지 못하는 경우가 존재할 수 있습니다.

결정(Decision)

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

    fun condition(x: Int, y: Int) {
        println("start") // (1)
        if (x > 0 && y < 0) { // (2)
            println("middle") // (3)
        }
        println("last line") // (4)
    }

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

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

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

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