• TDD

단계: 레드 - 그린 - 리팩토링

테스트 선 작성 후 테스트를 통과시킬 만큼의 코드를 작성한다.(기능을 구현한다)
마지막으로 리팩토링을 통해 코드를 다듬는다.
테스트를 통해 개발의 범위가 정해진다. 테스트가 진행될수록 검증하는 범위가 넓어지면서 기능 구현이 점점 완성되어간다.

TDD는 개발 과정에서 코드를 지속적으로 정리하므로 코드품질을 높이고 유지보수 비용을 낮춘다.
코드 수정 후 테스트가 진행되므로 향후 올바르지 않은 코드가 배포되는 것을 방지할 수 있다.

• 테스트 코드 작성 순서

1. 쉬운 경우(넓은 범위)에서 어려운 경우로 진행
2. 예외적인 경우에서 정상인 경우로 진행

한 번에 많은 코드를 만들면, 그 사이 발생한 버그를 잡기 위해 많은 비용이 들어간다.

1. 정해진 값 리턴
2. 값 비교를 통해 정해진 값 리턴
3. 다양한 경우 추가하면서 구현을 일반화

테스트를 먼저 작성하고 return 상수로 테스트 통과시킨 후에 비즈니스 로직 하나씩 추가하면서 테스트 매번 실행

• 대역

Mockito
memoryRepository implements 리포지토리 인터페이스 - Map 사용하기
@TempDir

• 기능명세

테스트할 기능을 생성하면서 클래스, 메서드, 파라미터 구성
결과 검증하면서 리턴값 구성
-> 테스트하면서 설계까지 진행됨
클래스, 메서드, 변수명은 주석보다 코드 이해에 효과적이게 구성하기

필요한만큼만 설계하기
예외적인 상황, 복잡한 상황은 최대한 많이 기획자와 상의하고 대비하는 것이 효율적이고 완성도 높은 개발을 이끌어냄

• 리팩토링

기능 개발을 다 끝낸 후에 리팩토링하기
또는 커밋 후에 리팩토링하기
리팩토링은 클래스 분리, 메서드 추출, or문, count 로직 등 이용...
파라미터 개수가 3개 이상이면 객체화하기

• 꿀팁
  • Assert 메서드를 테스트 클래스에 별도 생성해서 응용도 가능하다.
    로직을 중복 호출하지 않고, Assert 메서드에 로직을 넣어버려서 검증만 진행하도록 할 수도 있다.

• • 중간에 예외처리를 하면, 조건문 중복 등 코드가 복잡해지기 때문에
    초반에 예외처리를 하는 것이 시스템 운영 중에 NPE를 만나지 않는 방법이다.

• • before setUp으로 데이터를 미리 생성해놓는 것은 중복이 제거되는 듯이 보이지만,
    각 테스트마다 필요한 데이터가 항상 일정하지 않을 수 있음으로 각 테스트에서 데이터 생성하는 것을 추천한다.

• • 검증 시 굳이 변수나 필드명으로 검증하는 것보다 기댓값을 실제값으로 넣는 것도 좋다.
    테스트에서는 직관적으로 확인할 수 있는 것이 좋기 때문이다.

• • given으로 파라미터를 넘길 때는 값보다 타입으로 넘겨주자.(범용성)

• • update와 같은 내부구현 검증이 필수적일 때는 내부구현 검증이 필요하다.
    하지만 웬만하면 실행결과 검증 중심으로 진행할 것.
    테스트 실패의 경우를 줄이기 위해서 검증해야할 부분을 명확히 하기 위해서이다.