실제 테스트의 순서 정리

 

1. 요구사항 정의서에서 기술 도출

예를 들어 로그인 기능을 만든다고 한다면

- 회원가입 시에 데이터를 DB에 저장한다.

  ㄴ 1번 예외는 회원 ID의 Duplicate 예외를 체크해야한다.

  ㄴ 2번 예외로 제대로 데이터가 저장되었는지 select로 확인한다.

 

총 1번과 2번의 테스트가 필요할 것이다.

 

2. 위의 기능을 테스트하기 위해 테스트코드를 작성한다.

주의점은 테스트 코드를 먼저 만들어야하며, Dto 혹은 로직을 먼저 만들어선 안된다. 늘 끝에서 먼저 생각해야한다.

책의 내용을 정리해서 말하자면 그 이유는 중심에 있다고본다. 예외사항을 고려해서 실패 코드를 먼저 작성해야한다. 그렇게 예외를 던지는 값부터 거꾸로 올라가서 테스트하는데에 필요한 클래스, 메서드, 변수 등을 고민하며 테스트를 진행해야한다.

 

3. 점점 강도를 올리며 코드가 어려워 지는 것을 느끼면 리펙토링을 진행한다.

 

4. 익셉션은 미리 고민해서 만들지 말고, 필요한 순간에 만든다.

예를 들어 중복된 ID가 존재하는 경우 회원 가입에 실패하는 테스트를 추가하는 시점에 비로소 DupIdException 타입을 추가한다.

 

5. 요구사항의 초안이 끝까지 개발된다는 보장이 없다.

요구사항은 바뀌는 경우가 있으므로 처음에 필요하다고 생각했던 설계 요소가 구현과정에서 쓸모가 없어지기도 하고

반대로 처음에 예상하지 못했던 설계 요소가 나중에 출현하기도 한다. TDD는 미리 앞서서 코드를 만들지 않으므로 불필요한 구성 요소를 덜 만들게 된다.

 

 

 

* 이름은 설계에서 매우 중요하다. 설계 과정에서 구현하는 기능을 정확하게 표현하는 이름을 사용하는 것만큼 중요한 것은 없다.

잘못 지은 이름은 두고두고 개발자를 속인다.시간이 다소 걸리더라도 알맞은 이름을 찾아야 한다. 이름을 고민하는 시간을 아까워하지 말자.