kenback TDD 3부

25장. 테스트 주도 개발 패턴

테스트를 한다는 것은 무엇인가?

먼저, 테스트에 대한 명사적 의미와 동사적 의미를 구분해야 한다.
테스트를 갖고 있다 는 것은 자동화 테스트의 명사적 의미를 암시하고, 변화를 테스트한다는 것은 수동적인 테스트의 동사적 의미를 암시한다.

테스트를 언제 해야 하는가?

테스트 대상이 되는 코드를 작성하기 직전에 작성한다.

양성 피드백 고리(positive feedback loop)

시스템에서 어떤 활동을 더 많이 하도록 격려하게 되는 것. 짝수 개의 음적 연결이 있다면 양성 피드백이다.

스트레스를 많이 받으면 테스트를 점점 더 뜸하게 수행하고, 에러는 점점 많아진다. 자연스럽게 스트레스도 다시 많아진다.
이 고리를 빠져나오려면 다음을 고려할 수 있다.

• 새로운 요소 도입하기
• 기존 요소를 바꾸기
• 화살표를 바꾸기

기존 요소 바꾸기: 자동화 테스트

이 경우엔 테스트를 자동화된 테스트로 바꾸면 된다.
자동화된 테스트가 있다면, 스트레스를 받기 시작할 때 테스트를 실행할 것이고, 두려움을 지루함으로 바꿔주는 효과가 있다.

“음, 아무 문제 없군. 테스트가 여전히 초록 막대야.”

스트레스를 더 많이 받을수록 더 많은 테스트를 수행하게 되고, 작업 중에 에러를 낼 일은 줄어들면서 스트레스도 자연스럽게 줄어든다. 즉, 개발자의 멘탈을 위해서라도 테스트 자동화는 중요하다.

화살표 바꾸기: 테스트 우선

테스트를 먼저 해야 한다는 규칙을 도입한다.
테스트를 먼저 하면 스트레스는 줄고, 더 많은 테스트를 하게 된다.

테스트할 로직을 어떻게 고를 것인가?

각각의 테스트는 서로 완전히 독립적이어야 한다.

앞 부분에서 실행한 테스트가 실패하고, 그 영향으로 다음 테스트부터 시스템이 예측 불가능해지는 경우는 꽤 많다.
이 문제를 해결하기 위해 각 테스트 사이에서 매번 시스템을 재동하는 방법을 써봤지만, 시간이 너무 오래 걸린다. 이를 통해 테스트는 전체 애플리케이션을 대상으로 하는 것보다 좀 더 작은 스케일로 하는 것이 좋다는 것을 알 수 있다.

테스트를 격리하기 위해서는 결과적으로 주어진 문제를 작은 단위로 분리하고 각 테스트를 실행하기 위한 환경을 쉽고 빠르게 세팅할 수 있게 해야 한다. 결국 테스트를 격리하는 작업이 시스템을 응집도는 높고 결합도는 낮은 객체로 구성할 수 있도록 한다.

테스트 목록 작성하기: 작업 범위 조정

무엇을 테스트해야 하는가?

구현해야 할 것들에 대한 테스트들을 생각해본다.

• 요구사항에 대한 사용 예들을 적는다.
• 해당 요구사항에 관한 기능들이 아무 일도 하지 않는 버전으로 테스트할 수 있도록 할 일을 적는다.
• 클린코드를 위해 반드시 해야 하는 리펙토링 목록을 적는다.

모든 테스트를 한 번에 작성할 수도 있지만, 만들어둔 테스트는 리팩토링에 대한 관성을 가지게 마련이고, 초록 막대를 빠른 시일 내에 보기 어렵기 때문에 NO!
하나의 테스트를 통과하게 하는 과정에서 새로운 테스트가 필요해진다. 이를 할 일 목록에 적어두면 된다.

제대로 작동하지 않는 테스트 하나를 성공시키는 것이 코드를 release하는 것보다 중요하다.

단언 우선

테스트를 작성할 때 단언부터 작성한다.

• 시스템을 개발할 때 완료된 시스템이 어떨거라고 알려주는 이야기(user story)부터 작성한다.
• 특정 기능을 개발할 때 기능이 완료되면 통과할 수 있는 테스트부터 작성한다.
• 테스트를 개발할 때는 완료되면 통과해야 할 단언부터 작성한다.

단언을 먼저 작성하면 작업을 단순하게 할 수 있다.

예를 들어, 소켓을 통해 다른 시스템과 통신하는 것을 테스트하고자 한다. 통신을 마친 후 소켓은 닫혀 있고 소켓에서 “abc”를 읽어야 한다.

TEST(socketTest, transactionTest){
    ASSERT_TRUE(reader.isClosed()); //reader에서 socket이다.
    ASSERT_EQ("abc", reply.contents()); //reply에서 buffer의 존재가 필요하다. 
}

TEST(socketTest, transactionTest){
    Socket reader = Socket("localhost", defaultPort()); //서버 접속 전에 서버를 열어야 한다.
    Buffer reply = reader.contents();
    ASSERT_TRUE(reader.isClosed());
    ASSERT_EQ("abc", reply.contents());
}

TEST(socketTest, transactionTest){
    Server writer = Server(defaultPort(), "abc");
    Socket reader = Socket("localhost", defaultPort()); //서버 접속 전에 서버를 열어야 한다.
    Buffer reply = reader.contents();
    ASSERT_TRUE(reader.isClosed());
    ASSERT_EQ("abc", reply.contents());
}

작은 단계로 피드백을 받으며 테스트의 아웃라인을 작성할 수 있다.

테스트할 때 어떤 데이터를 사용할 것인가?

테스트를 읽을 때 가독성 높은 데이터(명백한 데이터)를 사용해야 한다.

• 데이터 값을 산발하지 말아야 한다.: 데이터를 무작위로 변경하거나 예상치 못한 상태로 만들지 말아야 한다.
• 데이터 간에 차이가 있다면 어떤 의미가 있어야 한다.
• 1과 2 사이에 어떤 개념적 차이가 없다면 1을 사용해야 한다.
• 여러 의미를 담고 있는 상수를 쓰지 말아야 한다.

테스트 데이터에 대한 대안은 실제 데이터를 사용하는 것이다.

(명백한) 데이터의 의도를 어떻게 표현할 것인가?

테스트 자체에 예상되는 값과 실제 값을 포함하고 이 둘의 관계를 드러내기 위해 노력해야 한다.
테스트를 작성할 때는 먼 훗날 코드를 읽을 개발자들도 생각해야 한다.

다음 코드는 은행의 환전 거래 코드이다.
환전하려고 하는데 수수료는 1.5%이고 USD와 GBP 환율은 2:1이다.

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

$100을 환전하면 50GBP - 1.5% = 49.25GBP이다.

수수료나 환율같은 경우, 더 명백한 데이터로 매직넘버를 쓸 수도 있다.

매직넘버

상수를 직접 쓰는 것을 의미한다. 일반적으로 적절한 기호상수를 정의하여 사용하는 것이 좋다.

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

이 테스트에서는 입력값과 예상값 사이의 관계를 읽을 수 있고, 나눗셈과 곱셈을 수행할 프로그램을 만들 것이라는 것을 알게 된다.
단일 메서드 범위라면, 이 명백한 데이터는 코드에 매직넘버를 쓰지 말라는 내용에 대한 예외적인 규칙일 수도 있다.

하지만, 이미 정의된 기호 상수가 있다면, 굳이 제거하지 말고 사용하도록 하자.

26장. 빨간 막대 패턴

테스트를 언제 어디에 작성할 것인지, 테스트 작성을 언제 멈출지에 대한 패턴이다.

시작 테스트

아무 일도 하지 않는 경우부터 테스트하자.

하나의 기능에 대한 현실적인 테스트를 하나 작성한다면 한꺼번에 많은 문제를 해결해야 한다.

1. 이 기능을 어디에 두나?
2. input은?
3. output은?

현실적인 테스트를 바로 구현하고자 한다면, 빨강-초록-리팩토링 주기는 길어지게 된다.

다각형 축소기를 TDD로 구현한다고 가정하자.
이 축소기는 다각형을 입력하면, 모든 꼭지점을 일정 비율로 축소시킨 다각형 중 가장 적게 꼭지점을 가지는 다각형을 생성해낸다.

1. 어떤 다각형은 더 축소할 수 없다.
2. 입력은 가능한 한 적어야 한다.

Reducer r = new Reducer(new Polygon());
ASSERT_EQ(0, r.result().npoints());

한 단계 테스트

목록에서 다음 테스트를 구현할 때 무엇을 기준으로 어떤 테스트를 구현할 지 선택할 것인가?

뻔하지 않고, 구현할 수 있다는 확신이 드는 테스트를 뽑을 것

상향식, 하향식으로 작성하는 프로세스는 TDD를 효과적으로 설명할 수 없다.

상향식(bottom-up)

모듈부터 차례로 구현하고 테스트하면서 기능을 추가해나가는 것

하향식(top-down)

큰 문제를 해결하기 위해 작은 단위로 쪼개어 구현해나가는 것. 전체 설계 => 하위 기능 구현

두 방식 모두 프로그램이 시간에 따라 어떻게 변하는지에 대한 시각일 뿐이다.

방향성을 가진다면,

아는 것에서 모르는 것으로(known-to-unknown) 방식이 유용하다.

말하자면, 지식이나 데이터를 이용하여 이를 기반으로 새로운 정보나 통찰력을 얻고, 그로 인해 계속해서 발전하고 성장하게 된다.

설명 테스트

테스트를 통해 설명을 요청하고, 테스트를 통해 설명하자.

TDD를 널리 쓰이게 만드는 방법 중 하나일 수 있다.
사람들에게 “TDD로 바꿔서 해봐!”라고 밀어붙이는 것만큼 TDD가 퍼지는 것을 확실하게 막는 것은 없다.
TDD의 여러 가지 이점을 드러내 자연스럽게 문화로 정착시켜야 한다.

“Foo를 이렇게 설정하고, Boo를 이렇게 설정하면 1이 나와야 합니다. Foo가 저렇고, Boo가 저러면 2입니다.”

좀 더 추상적으로도 가능하다.
누군가 sequence diagram을 설명하려고 한다면, 이 다이어그램에 나타난 모든 요소를 포함하는 테스트 케이스를 작성하면 된다.

학습 테스트

외부에서 만든 소프트웨어에 대한 테스트를 작성할 때, 우리가 예상한 대로 API가 실행된다는 것을 확인해줄 만한 작은 테스트를 만들어보자.

만약 API를 제대로 이해했다면, 테스트도 바로 통과할 것이다.
또한 패키지의 새 버전이 나오면, 우선 테스트를 실행해보고, Fail하면 앱을 실행시켜볼 필요도 없다.

Record store(외부 패키지)에 어떤 데이터를 저장하고, 이를 받아온다고 가정하자.

TEST(PackageTest, RecordStoreTest){
    RecordStore store;
    store = RecordStore.openRecordStore("testing", true);
    int id = store.addRecord(new unsigned char[2] {5, 6}, 0, 2);
    unsigned char* buffer = new unsigned char[2];
    ASSERT_EQ(2, store.getRecord(id, buffer, 0));
    ASSERT_EQ(5, buffer[0]);
    ASSERT_EQ(6, buffer[1]);
}

또 다른 테스트

현재 구현하고 있는 테스트와 무관한 아이디어가 떠오른다면, 할 일 목록에 적어두고 다시 주제로 돌아오자.

회귀 테스트(regression test)

회귀 테스트

소프트웨어의 변경 사항이나 수정 사항을 테스트함

1. 기존에 작성된 테스트를 선택한다.
2. 변경된 소프트웨어 버전을 적용한다.
3. 실행 결과를 예상 결과와 비교한다.
4. 변경 사항에 의해 영향을 받은 기능들을 식별하고, 해당 부분을 수정하고 추가 테스트 케이스를 작성한다.
5. 모든 테스트 케이스가 예상한 대로 작동할 때까지 회귀 테스트를 반복한다.

회귀 테스트의 가치는,

1. 앱 차원에서는 시스템 사용자들이 어떤 것을 기대했고, 어떤 것이 현재 잘못되었다는 것을 알 수 있다.
2. 현재 가지고 있는 테스트를 개선할 수 있다.
   • 매우 큰 음수에 대한 결함 보고서가 있다면, 정수 롤오버를 테스트해야 한다는 것을 배울 수 있다.

시스템 장애를 쉽게 해결할 수 없다면 리팩토링해야 한다.

휴식

아무것도 모르겠으면, 일단 좀 쉬어도 된다.

물론 계속 쉬기만 하면 안되고, 무엇을 해야 할 지 고민하는 시간이 필요하다는 뜻이다.

다시 하기

진짜 모르겠으면, 코드를 다 지우고 처음부터 다시 하자.

싸구려 책상, 좋은 의자

의자는 최고급으로 써라.

익스트림 프로그래밍에서 권장하는 사무실 배치는 파티션이 없는 넓은 공간 가운데에 큰 테이블을 놓고, 개발자들이 둘러 앉는다.
개인이 사적으로 사용할 컴퓨터는 구석에 따로 배치한다.
이러한 개발 환경은 팀 내 의사 소통을 원활하게 해주며 생산성을 크게 높여준다.