테스트 주도 개발 - 3부 26장

26장 빨간 막대 패턴

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

 

한 단계 테스트

목록에서 다음 테스트를 고를 때 무엇을 기준으로 할 것인가? 여러분에게 새로운 무언가를 가르쳐줄 수 있으며, 구현할 수 있다는 확신이 드는 테스트를 고를 것. 각 테스트는 우리를 최종 목표로 한 단계 진전시켜 줄 수 있어야 한다. 다음 테스트 목록 중 무엇을 고르는게 좋을까?

• 더하기
• 빼기
• 곱하기
• 나누기
• 비슷한 것 더하기
• 동치성(equals)
• 널과의 동치성(equals null)
• 널 환전
• 한 개의 통화를 환전하기
• 두 개의 통화를 환전하기 
• 환시세 

정답은 없다. 이 목록에서 한 단계 전진을 나타낼 만한 것을 못 찾았다면 직접 하나 추가해 보기 바란다.

 

전체 계산 중 간단한 하나의 사례를 나타내는 테스트에서 시작했다면, 이 테스트를 통해 자라는 프로그램은 하향식으로 작성된 것으로 보일 수 있다.

반면 전체의 작은 한 조각을 나타내는 테스트에서 시작하여 조금씩 붙여나가는 식이었다면, 이 프로그램은 상향식으로 작성된 것으로 보일 수 있다. 

사실은 상향식, 하향식 둘 다 TDD의 프로세스를 효과적으로 설명해 줄 수 없다.

첫째로 이와 같은 수직적 메타포는 프로그램이 시간에 따라 어떻게 변해 가는지에 대한 단순화된 시각일 뿐이다.

둘째로, 만약 메타포가 어떤 방향성을 가질 필요가 있다면 '아는 것에서 모르는 것으로' 라는 방향이 유용할 것이다.

'아는 것에서 모르는 것으로'는 우리가 어느 정도의 지식과 경험을 가지고 개발을 시작한다는 점, 개발하는 중에 새로운 것을 배우게 될 것임을 예상한다는 점 등을 암시한다.

 

시작 테스트

어떤 테스트부터 시작하는 게 좋을까? 오퍼레이션이 아무 일도 하지 않는 경우를 먼저 테스트할 것.

첫 걸음으로 현실적인 테스트를 하나 작성한다면 상당히 많은 문제를 한번에 해결해야 하는 상황이 될 것이다.

• 이 오퍼레이션을 어디에 두어야 하나?
• 적절한 입력 값은 무엇인가?
• 이 입력들이 주어졌을 때 적절한 출력은 무엇인가?

현실적인 테스트 하나로 시작하면 너무 오랫동안 피드백이 없을 것이다. 빨강/초록/리팩토링, 빨강/초록/리팩토링. 우리는 이 고리가 몇 분 이내로 반복되길 원할 것이다.

정말 발견하기 쉬운 입력과 출력을 사용하면 이 시간을 짧게 줄일 수 있다.

다각형 축소기에 대한 질문 "테스트를 작동하도록 하는 데 박사 학위 논문을 읽어야 하는 경우, 이 문제를 어떻게 테스트 주로 접근할 수 있을까요?" 시작 테스트 패턴이 이 문제에 대한 답을 준다. 

• 출력이 입력과 같은 경우가 있다. 어떤 형상(configuration)의 다각형들은 이미 정규화되어 있고 더 축소할 수 없다.
• 입력은 가능한 한 적어야 한다. 이를테면 다각형 하나 또는 아예 비어있는 다각형 목록일 수도 있다. 

본인에게 뭔가를 가르쳐줄 수 있으면서도 빠르게 구현할 수 있는 테스트를 선택하라.

만약 본인이 어떤 애플리케이션을 n번째 구현하고 있다면, 오퍼레이션을 한두 개 필요로 하는 테스트를 하나 골라라.

본인 스스로 그걸 작동하게 할 수 있을 거라 자신할 것이다. 많은 경우 나의 시작 테스트는 그 이후의 테스트에 비해 좀더 높은 차원의 테스트로, 애플리케이션 테스트와 비슷하다.

 

설명 테스트

자동화된 테스트가 더 널리 쓰이게 하려면 어떻게 해야 할까? 테스트를 통해 설명을 요청하고 테스트를 통해 설명하라. TDD의 사용을 강요하는 것 만큼 TDD가 퍼지는 것을 빨리 막는 방법은 없다. 타인의 일하는 방식을 강제로 바꿀 수는 없다. 어떻게 해야 하나? 단순한 시작법은 테스트를 이용하여 묻고, 테스트를 이용하여 설명하는 것이다. 

 

학습 테스트

외부에서 만든 소프트웨어에 대한 테스트를 작성해야 할 때도 있을까? 

패키지의 새로운 기능을 처음으로 사용해보기 전에 작성할 수 있다.

만약 우리가 API를 제대로 이해했다면 이 테스트는 한번에 통과할 것이다. 아래는 학습 테스트를 작성하는 관례를 설명한다. 

• 패키지의 새 버전이 도착하면 우선 테스트를 실행한다(그리고 필요하다면 수정한다).
• 만약 테스트가 통과되지 않는다면 애플리케이션 역시 실행되지 않을 것이 뻔하기 때문에 애플리 케이션을 실행해볼 필요도 없다.
• 일단 테스트가 통과한다면 애플리케이션은 항상 제대로 돌아갈 것이다

또 다른 테스트

어떻게 하면 주제에서 벗어나지 않고 기술적인 논의를 계속할 수 있을까? 주제와 무관한 아이디어가 떠오르면 이에 대한 테스트를 할일 목록에 적어놓고 다시 주제로 돌아와라.

대화를 엄격하게 한 주제로 묶는 것은 훌륭한 아이디어를 억압하는 최고의 방법이다. 하루 온종일 비생산적인 날들을 보낸 경험에서, 내가 가야 할 길을 놓치지 않는 것이 때로는 최선임을 배웠다. 새 아이디어가 떠오르면 존중하고 맞이하되 그것이 내 주의를 흩뜨리지 않게 한다. 그 아이디어를 리스트에 적어놓고는 하던 일로 다시 돌아간다. 

 

회귀 테스트

시스템 장애가 보고될 때 우리는 무슨 일을 제일 먼저 하는가? 그 장애로 인하여 실패하는 테스트, 그리고 통과할 경우엔 장애가 수정되었다고 볼 수 있는 테스트를 가장 간단하게 작성하라. 

회귀 테스트(regression test)란, 사실 여러분에게 완벽한 선견지명이 있다면, 처음 코딩할 때 작성했어야 하는 테스트다. 회귀 테스트를 작성할 때는 이 테스트를 작성해야 한다는 사실을 어떻게 하면 애초에 알 수 있었을지 항상 생각해보라.

전체 애플리케이션 차원에서 테스트를 수행하는 것에서도 가치를 얻을 수 있다. 애플리케이션 차원의 회귀 테스트는 시스템의 사용자들이 여러분에게 정확히 무엇을 기대했으며 무엇이 잘못되었는지 말할 기회를 준다. 좀더 작은 차원에서의 회귀 테스트는 당신의 테스트를 개선하는 방법이된다. 기괴할 정도로 큰 음수에 대한 결함보고서가 있을 수 있다. 여기에서는 테스트 목록을 작성할 때 정수 롤오버를 테스트할 필요가 있다는 것을 배울 수 있다. 

시스템 장애를 손쉽게 격리시킬 수 없다면 리팩토링해야 한다. 이러한 종류의 장애가 있다는 것은, 시스템의 설계가 아직 끝나지 않았다는 뜻이다.

 

휴식 

지치고 고난에 빠졌을 땐 뭘 해야 하나? 그럴 땐 좀 쉬는게 좋다.

당신이 결정한 것에 대한 감정적 책임과 당신이 타이핑해 넣은 문자들을 손에서 깨끗이 씻어 버리도록 하라. 종종 이 정도의 거리 두기를 통해 당신에게 부족했던 아이디어가 튀어나올 수 있다. 다음과 같은 생각이 들면 여러분은 벌떡 일어날 것이다 "매개 변수를 뒤집은 상태에서 시도한 적은 없었지!" 어찌됐건간에 좀 휴식을 취하라. 만약 그러한 아이디어를 얻지 못한다면, 현재 세션의 목적을 다시 검토해 보라. 여전히 현실적인가, 아니면 새로운 목적을 골라야 하는가? 당신이 이루려고 노력했던 것이 불가능한 건 아닌가? 만약 그렇다면 팀에는 어떤 의미가 있나? 

데이브 웅가(Dave Ungar)는 이걸 샤워 방법론이라고 부른다. 키보드로 뭘 쳐야 할지 알면, 그걸 치면 된다. 뭘 해야 할지 모르겠으면 샤워하러 가서 뭘 해야 할지 생각날 때까지 계속 샤워를 한다. 그의 방법론을 따른다면 많은 팀들이 더 행복해질 것이고 생산성도 향상될 것이며 냄새도 훨씬 덜 날것이다. TDD는 웅가의 샤워 방법론을 정제한 것이다. 키보드로 뭘 쳐야 할지 알면, 명백한 구현을 한다. 잘 모르겠다면 가짜 구현을 한다. 올바른 설계가 명확하지 않다면 삼각측량 기법을 사용한다. 그래도 모르겠다면 샤워나 하러 가는 거다. 

 

다시 하기 

길을 잃은 느낌이 들 땐 어떻게 할까? 코드를 다 지워버리고 처음부터 다시 해보자. 

한 시간 전까지만 해도 잘 돌던 코드가 뒤죽박죽이 됐다. 다음 테스트를 어떻게 통과시켜야 할지도 모르겠고, 앞으로 20개나 되는 테스트를 다 구현해야 한다. 이런일은 자주 있다. 내 본능적인 반응은 꼬인 코드를 계속 진행할 수 있을만큼만 풀어놓자는 것이다. 숙고해보기 위해 잠깐 멈추어 생각해보면, 처음부터 다시 하는 게 항상 더 합리적이라는 결론이 났다. 

 

싸구려 책상, 좋은 의자 

TDD를 할 때 어떤 물리적 환경이 적절한가? 나머지 시설은 싸구려를 쓸지라도 정말 좋은 의자를 구해라. 

허리가 아프면 프로그램을 잘 짤 수가 없다.