테스트주도개발 03

테스트 주도개발 3장

3.1 테스트 케이스 클래스 위치

1. 테스트 대상 소스와 테스트 클래스 같은 곳에

1. 간단한 테스트 만들 때만 사용

2. 테스트 클래스는 하위 패키지로

3. 최상위 패키지를 분리

• 업무코드와 테스트 코드를 분리해서 찾기 쉬움
• default나 protected 로 선언된 메소드에 대해서 테스트 코드 작성 불가

##### 4. 소스 폴더는 다르게 패키지는 동일, 컴파일된 클래스는 각각 다른 곳으로 (추천 스타일)

• 대상 클래스와 테스트 클래스를 동일한 패키지로 선언 가능
• default나 protected 로 선언된 메소드도 테스트 가능
• 업무 코드와 테스트 코드가 컴파일 시 최상위 폴더가 달라 섞일 염려가 없음
• 그래서 배포가 쉽고 빠른 패키징이 가능
• 가장 권장하는 테스트 스타일

5. 테스트를 프로젝트로 분리

• 4번으로 한다해도 동일 프로젝트에 있다면 결국 각자 사용하는 라이브러리의 경우 클래스패스로 공유함
• 이렇게 되면 각각 사용되는 라이브러리를 구분하기 어려움
• 배포시에 일일이 구분해야하는 어려움 발생

6. 메이븐 스타일

• CoC 사상 기반의 Maven을 사용할 경우 기본적으로 구성되는 구조.
  • CoC (Convention over Configuration) :설정보다는 관례. 환경 구성을 위해 설정 작업을 일일이 따지기 보다 일반적인 관례, 환경 구성을 그대로 이용한다는 사상.
• 제품 코드에 필요한 리소스와 테스트에 사용하는 리소스를 분리해서 관리하기 편함

위치	설명
/src/main/java	제품 코드가 들어가는 위치
/src/main/resources	제품 코드에서 사용하는 각종 파일, XML 등의 리소스 파일들
/src/test/java	테스트 코드가 들어가는 위치
/src/test/resources	테스트 코드에서 사용하는 각종 파일, XML 등의 리소스 파일들

** 내 생각 : 오래된 책이라 maven 방식이 국내에 아직 많지 않다고 한다. 요즘은 이게 거의 대세 아닌 표준인듯?

3.2 테스트 메소드 작성 방식

1. 테스트 대상 메소드와 이름을 1:1 일치

/* 테스트 대상 코드 */
public int getBalance {… }

/* 테스트 코드 */
@Test
public void testGetBalance{… }

2. 테스트 대상 메소드의 이름 뒤에 추가적인 정보를 기재

• 가장 권장하는 방식
• 저자는 _뒤로 한글로 작성하는거 추천한다고 함. Good? 세종대왕 만세

/* 테스트 대상 코드 */
public void withdraw(int money) {… }

/* 테스트 코드 */
@Test
public void testWithdraw_마이너스통장인출( ){ … }
@Test
public void testWithdraw_잔고가0원일때( ){ … }

3. 테스트 시나리오에 집중

/* 테스트 대상 코드 */
// 특정한 메소드를 대상으로 하기보다는 테스트 시나리오 대상이 된다.

/* 테스트 코드 */
@Test
public void VIP고객이_인출할때_수수료계산( ){ … }
@Test
public void 일반고객이_인출할때_수수료계산( ){ … }

• 선조건 > 수행 > 예상 결과 식의 테스트 시나리오를 갖음.

3.3 테스트 케이스 작성 접근 방식

• 무엇을 테스트 케이스로 작성할 것인가?

• 『실용주의 프로그 래머를 위한 단위 테스트 with JUnit』(인사이트) 추천

3.4 TDD의 한계

1. 동시성 문제

• (책에서 말하는게 뭔소리인지 모르겠음) 근데 대부분 가능하다고 함.

2. 접근 제한자(private / protected 메소드)

• public으로 되어 있는 메소드만 테스트해도 무방하다.
• 왜냐하면 private 메소드는 public 메소드 들이 사용하는 메소들이기 때문이다.
• 따라서 public 메소드가 테스트 될 때 private도 같이 테스트가 이뤄진다고 보기 때문
• 때로는 모든 메소드를 public으로 만들어서 테스트를 진행하고 난 후에 차후 private으로 바꾸는 방식으로 접근하는 것도 좋다.
• 이때 기존 생성한 테스트 케이스는 지우지 말고 주석 형태로 남기는 것이 좋다.

3. GUI

• 이건 뭐… 넘어가장

4. 의존성 모듈 테스트 (target = A but A->B)

• 테스트 대상이 되는 A가 기타 메소드나 클래스를 참조할 경우
• 그리고 해당 참조 부분에 대한 접근이 쉽지 않을 경우 B는 어떻게 할 것인가?
• B가 문제 없는 모듈이면 상관 없지만 아닐 경우 문제
• 이럴 경우 B를 신뢰한다는 가정하에 가던가 Mock 객체를 사용