명세 기반 테스트

명세 기반 테스트 기법 적용하여 테스트 케이스 작성하는 방법

1단계: 요구사항과 입출력에 대해 이해하기

요구사항을 어떻게 작성했든 세부분으로 이루어져있다.

프로그램 또는 메서드는 무엇을 수행하는가(비즈니스 규칙)
프로그램은 데이터를 입력으로 받는다.
출력에 대한 추론은 프로그램이 무엇을 수행하고 입력이 어떻게 기대하는 출력으로 변환되는지 더 잘 이해하도록 해준다.

2단계: 여러 입력값에 대해 프로그램이 수행하는 바를 탐색하기

메서드가 수행하는 작업을 탐색하면 메서드를 잘 이해할 수 있다. 직접 가지고 놀며 프로그램을 더 잘이해하도록 해보자.

3단계: 테스트 가능한 입출력과 구획을 탐색하기

프로그램의 정확성을 충분히 확신할 수 있도록 입출력에 대해 우선순위를 매기고 그 일부를 선택하는 방법을 찾아야 한다. 프로그램에 대해 가능한 입력과 출력의 수는 거의 무한대이지만, 프로그램은 일부 입력 집합에 대해 특정 입력값에 관계없이 동일한 방식으로 동작

How? 다음과 같이 생각

각각의 입력에 대해: '내가 전달하는 입력이 어떤 부류에 해당하는가?'
각 입력과 다른 입력의 조합에 대해 'open 태그와 close 태그 사이에 어떤 조합을 만들 수 있을까?
이 프로그램에서 기대하는 여러 부류 출력에 대해 '배열을 리턴하는가? 빈 배열을 리턴하는가? 널을 리턴하는가?

입력 변수 자세히 분석하고 변수들의 가능한 조합을 살펴보고 출력에 대해 생각

4단계: 경계 분석하기

버그는 입력 도메인의 경계에서 흔하게 발생한다. 구획을 설계 할 때 한 구획은 다른 구획과 가까운 경계를 지닌다. 경계를 발견할 때마다 입력을 한 경계에서 다른 경계로 이동시키며 프로그램에 어떤 일이 일어나는지 테스트하자.

5단계: 테스트 케이스 고안하기

앞에서 입력, 출력, 경계를 적절하게 해부했으니 이제 구체적인 테스트 케이스를 만들자. 앞에서 찾은 모든 구획을 결합할 수 있을 것이다. 하지만 모두다 작성하는 건 노력에 비해 성과가 크지 않기 때문에 구획을 어떻게 조합할지 실용적으로 결정해야 한다.

즉, 구획을 무작정 조합하지 말고 어떤 구획을 확장해서 테스트해야하는지 어떤 구획은 그렇게 하지 않을지 명확히 파악하고 나면, 조합을 통해 여러 ㅌ스트 케이스를 도출한다. 먼저 예외 케이스를 고려

6단계: 테스트 케이스 자동화하기

테스트를 자동화하는 일은 거의 기계적인 작업이다. 창의성이 필요한 부분은 특정 구획에 입력을 넣고 그 구획에 대한 프로그램의 출력을 이해하는 일이다. JUnit을 이용해 다음과 같이 테스트 할 수 있음

@Test
void noSubstringBetweenOpenAndCloseTags() {
  assertThat(substringsBetween("aabb", "aa", "bb")).isEqualTo(new String[] {""});
}

또한, 여러개의 값들을 주입할 수 있는 ParameterizedTest를 이용해 좀 더 편리하게 테스트를 해볼 수도 있다.

7단계: 창의성고 경험을 발휘해서 테스트 스위트를 강화하기

체계적인 것도 좋지만 우리의 경험을 무시해서는 안된다. 이번 단계에서는 우리가 고안한 구획을 살펴보고 흥미로운 변형을 찾아 낼 수 있는지 살펴보자.

현업에서의 명세 테스트

프로세스는 연속적이 아니라 반복적이어야 한다.

위에서 본 7단계는 순차적인 프로세스가 아니라 전체 프로세스는 반복적이다. 즉, 다른 단계들 사이를 왔다 갔다 해야한다. -> 테스트 케이스를 작성할 때 구획이나 경계를 놓쳤다는 것을 알게 되면 다시 돌아가서 테스트 스위트를 개선

명세 테스트는 어느 정도로 수행해야 하는가?

실패의 위험성을 이해해야 한다. 프로그램이 어떤 부분에서 실패하면 비용이 얼마나 들까? 비용이 높은 경우라면 테스트에 더 투자를 하고, 더 많은 코너 케이스를 탐색하고 품질을 보장하기 위해 다양한 기술을 시도하는 것이 현명할 수 있다. 이 책의 저자는 모든 단계를 몇번 거쳤는데도 테스트하지 않는 경우를 찾을 수 없을 때 테스트를 중단한다고 한다.

이해를 높이기 위해 입력을 변경해서 사용하자

모든 테스트에 동일한 입력 시드를 사용함으로써 다양한 테스트 케이스에 대한 이해를 단순화할 수 있다. 하지만 이 방법은 가능한 다양한 입력을 테스트하는 일반적인 테스트 개념에 위배되어 주의해야 한다. 입력 공간을 살펴보고 코너 케이스를 식별할 수 있기 때문에 다양한 입력은 필수다.

조합의 수가 폭발적으로 증가한다면 실용적이어야 한다.

첫째, 가능한 한 조합의 수를 줄이도록 하자. 다른 동작과 동떨어진 예외적인 동작을 테스트하는 것도 한 가지 방법이다. 또한 도메인 지식을 활용하여 조합의 수를 더 줄일 수 있다.

둘째, 메서드 수준에서 많은 조합이 발생한다면 메서드를 두 개로 나누는 것을 고려하자. 두 개의 작은 메서드는 테스트 할 대상이 적기 때문에 테스트할 조합이 적다. 메서드의 계약과 그 계약이 정보를 전달하는 방법을 잘 만들면 된다.

무엇을 입력할지 모르겠다면 간단한 입력을 넣어보자

테스트 케이스에 무엇을 입력할지 선택하는 것은 까다로운 일이다. 복잡한 입력을 사용해야 하는 충분한 이유가 없다면 이를 선택하지 않는게 좋다. 단순함이 중요하다.

관심 없는 입력에 대해 합리적인 값을 선택하자

떄로는 기능의 특정 부분을 수행하는 것을 목표로 할 수 있따. 그 부분은 입력값 중 하나를 사용하지 않을 수 있는데 이 '쓸데없는' 입력변수에 아무 값이나 전달할 수 있다. 이때 입력으로는 현실적인 값을 전달하자.

널과 예외 케이스는 의미가 있을 때만 사용하자

널과 예외적인 경우에 대한 테스트는 개발자가 종종 코드에서 이러한 경우를 처리하는 것을 깜박하기 때문에 항상 중요하다. 테스트 중인 코드가 UI와 매우 관련이 있는 경우라면 널, 빈 문자열, 일반적이지 않은 정숫값 등과 같은 코너 케이스를 더 많이 수행하자. 코드가 UI와 별로 관련이 없고 데이터가 테스트 대상 구성요소에 도달하기 전에 검사된 것이 확실하다면 이러한 테스트를 건너 뛸 수 있다.
-> 즉 버그를 잡을 수 있는 테스트만 작성하자.

테스트가 동일한 스켈레톤을 갖는 경우 매개변수화 테스트를 사용하자

약간의 중복은 결코 문제가 되지 않지만 많은 중복은 문제가 된다. 그것이 결국 관리 포인트가 되기 때문이다. 중복이 너무 많을 때 매개변수 테스트를 사용해 좀 더 편리하게 테스트를 해볼 수 있다.

다음과 같이 사용해볼 수 있다.

// 사용한 경우
@ParameterizedTest
@CsvSource(value = {"test,TEST", "tEst,TEST", "Java,JAVA"})
void toUpperCase(String actual, String expected) {
    assertEquals(actual.toUpperCase(), expected);
}

//사용하지 않은 경우
@Test
void toUpperCase1(String actual, String expected) {
    String expected = "TEST"
    String actual = "test"

    assertEquals(actual.toUpperCase(), expected);
}

@Test
void toUpperCase2() {
    String expected = "tEst"
    String actual = "TEST"

    assertEquals(actual.toUpperCase(), expected);
}

@Test
void toUpperCase3() {
    String expected = "Java"
    String actual = "JAVA"

    assertEquals(actual.toUpperCase(), expected);
}

Chapter2 한 줄 평

그 동안은 감으로 테스트를 몇개 작성했었는데 좀 더 체계적인 방법을 배운 거 같아 너무 좋은 것 같습니다~ 어떻게 테스트를 작성하면 좋을지에 대해 많이 배웠습니다. 이를 토대로 체계적인 방법 + 경험적인 측면을 이용해 테스트를 잘 짜도록 해보겠습니다.

CHAPTER 2 명세 기반 테스트 #2

Description

범위

기간

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions