Location of test case class
#1. 테스트 대상 소스와 테스트 클래스를 같은 곳에
e.g. chapter1을 기준으로 예를 들자면 Account.java와 AccountTest.java가 같은 패키지 안에 있는 형태
#2. 테스트 클래스는 하위 패키지로
e.g. Account.java는 bank 패키지에, AccountTest.java는 bank.test 패키지에
#3. 최상위 패키지를 분리
e.g. Account.java는 main 패키지에, AccountTest.java는 test 패키지에
#4. 소스폴더는 다르게, 패키지는 동일, 컴파일된 클래스는 각각 다른 곳에 (추천)
위와 같은 형태라고 보면 된다..
#5. 테스트 케이스를 프로젝트로 따로 뺀다.
#6. Maven style
/src/main/java 제품 코드
/src/main/resources 제품코드에서 사용하는 리소스 파일
/src/test/java 테스트 코드
/src/test/resources 테스트 코드에서 사용하는 리소스 파일
위와 같은 형태로 메이븐 스타일이 구성된다. 메이븐을 사용한다면 보게되는 스타일.
테스트 메소드 작성 방식
#1. 테스트 대상 메소드와 이름을 1:1로 일치
e.g.
public int getBalance() VS public void testGetBalance()
#2. 테스트 대상 메소드의 이름 뒤에 추가적인 정보를 기재
e.g.
public void getBalance() VS public void testGetBalance_잔고출력()
#3. 테스트 시나리오에 집중
테스트 코드에 시나리오적인 정보를 담아 메소드 생성.
TDD의 한계
- 동시성문제
concurrency가 걸려 있는 코드에 대한 테스트 케이스. 이런 경우는 테스트 자체의 무결성을 유지하는게 좀 힘들다.
- 접근 제한자
private method는 테스트가 불가능한데 public만 테스트 해도 무방하다는 의견이 대세. 왜냐하면 private들은 보통 public들이 사용하니까
- GUI
화면 레벨에서는 가급적 로지컬한 부분을 넣지 않도록
- 의존성 모듈 테스트
의존성 제거를 위해서 Mock을 사용합시다.
