3주차 회고

1. 단위 테스트

테스트하기 어려운 영역을 구분하고 분리하기

• 외부로 분리할수록 테스트 가능한 코드는 많아진다.

• 테스트가 어려운 부분을 분리해서 테스트 가능한 영역을 많이 만들자

테스트하기 어려운 영역

• 관측할 때마다 다른값에 의존하는 코드

  • 현재 날짜/시간 , 랜덤값 , 전역 변수 / 함수 , 사용자 입력

• 외부세계에 영향을 주는 코드

  • 표준 출력 . 메세지 발송 , db에 기록하기 등

순수함수 (테스트하기 쉬운 함수)

• 같은 입력에는 항상 같은 결과

• 외부 세상과 단절된 형태

• 테스트하기 쉬운 코드

• lombok

• @Data , @Setter , @AllArgsConstructor 사용 지양

• 양방향 연관관계 시 @ToString 순환 참조 문제

2. TDD

• 프로덕션 코드보다 테스트 코드를 먼저 작성하여 테스트가 구현 과정을 주도하도록 하는 방법론

• 테스트를 먼저 작성하고 기능 구현

• red - 실패하는 테스트 작성

• green - 테스트 통과 최소한의 코딩

• refactor(blue) - 구현 코드 개선 , 테스트 통과 유지

선 기능 구현 , 후 테스트 작성

• 테스트 자체의 누락 가능성

• 특정 테스트 케이스(해피 케이스)만 검증할 가능성

• 잘못된 구현을 다소 늦게 발견할 가능성

선 테스트 작성 , 후 기능 구현

• 복잡도가 낮은 (유연하고 유지보수가 쉬운) 테스트 가능한 코드를 구현할 수 있다

• 쉽게 발견하기 어려운 엣지 케이스를 놓치지 않게 해준다

• 구현에 대한 빠른 피드백을 받을 수 있다

• 과감한 리팩토링이 가능해진다

   

  ---

  회고

• 시험이 있어서 진도를 많이 따라가지 못해서 돌아오는 주에는 진도를 열심히 따라가야겠다.

• 단위 테스트 작성 과제를 제출하지 못했지만 추후에 강의를 다듣고 한번 진행해보는게 좋을거 같다.