3장 - TDD 좀 더 잘하기

[doortts]

@doortts (doortts) 님이 작성한 이슈입니다. ---

이전: 2장 - JUnit and Hamcrest 다음: 4장 - Mock 을 이용한 TDD

안내: 본문을 읽지 않고 아래의 코멘터리만 읽는 걸 가정해서 작성하진 않았습니다.

3장 본문

03-DoingBetterTDD.pdf

읽기전에

• "3.1 테스트 케이스 클래스의 위치" 부분은 Java 기준으로 "#6. 메이븐(Maven) 스타일"만 읽으면 될 것 같습니다.
• 전반적으로 짧은 챕터입니다. 시간들일 가치도 별로 크지 않으니 휙~ 보세요.

보충 설명

• "3.2 테스트 메소드 작성 방식" 은 봐둘만 합니다.
  • 특별히 추가 테스트가 필요 없는 기본 동작 테스트시에는 "테스트 대상 메소드와 이름을 1:1로 일치"
  • 몇 가지 조건절 테스트가 필요한 경우에는 "테스트 대상 메소드의 이름 뒤에 추가적인 정보를 기재"
  • 여러 메소드를 조합해서 테스트가 필요한 business 로직 테스트에는 "테스트 시나리오에 집중" 방식을 씁니다.
  • 현재도, 그리고 javascript 기반 개발시에도 BDD(Behavior Driven development) 사용 유무와 별개로 위 세 가지 스타일 중 필요한 방식으로 사용해서 개발하고 있습니다.
• 접근제한자(private/protected 메소드)의 경우 아무리 public 에서 테스트가 같이 된다고 해도 '역시 테스트 안하고 넘어가긴 찜찜하다' 싶은 사람들은 PowerMock을 사용하더군요.
  • 접근제한 메소드의 테스트가 필요한 경우 전 보통 public 만들어서 테스트 하고 끝나면 private 등으로 변경하고, 테스트 케이스는 @ignore 지정하고 끝냅니다.
  • 보통 다른거(junit, mockito 등) 쓰다가 private 메소드 테스트 하겠다고 powermock 도입하는 경우가 많은데 그것도 세팅하고 사용법 배우려면 시간대비 효용이 얼마나 큰지는 잘 모르겠다고 생각하거든요.
• "3.4 TDD의 한계" 에서는 기술적 관점에서 한계만 다루고 있습니다.
  • TDD의 사회적인, 그리고 심리적이며 환경역학적인 한계에 대해서는 뒷 부분에서 따로 다룰 예정입니다.

도전과제

• (별다른 기대는 안합니다만) 본인에 만든 테스트 케이스의 이름들이나 스타일을 주변 사람에게 공유하고 어떤지 물어보세요.

4장 예고

오늘은 금요일입니다. 전 벌써 고기를 몇 점 먹었다죠! 다음 업로드는 주말 건너뛰고 월요일에 이어집니다. 그럼 TGIF(Thank God It's Friday) 되세요~

--- attachments --- 03-DoingBetterTDD.pdf 29-20187-20-2037-3.png

[doortts]

@mjpark03-yona (박미정) 님이 작성한 코멘트입니다. ---

• 접근제한 메소드의 테스트가 필요한 경우 전 보통 public 만들어서 테스트 하고 끝나면 private 등으로 변경하고, 테스트 케이스는 @ignore 지정하고 끝냅니다.
  • 저는 이 부분에서 고민했던 점이, 내가 없는 상황에서 새롭게 이 테스트 코드를 접하는 사람이 느끼게 될 당황스러움(?) 이었습니다. :))