07. 25

• base entity는 여러개여도 된다.
• 모든 엔터티에 무조건 있어야 하는 느낌
• 만약 id가 long이 아니게 된다면?
• id가 없는 테이블도 있을 수 있다.

• Id를 userId 등으로 바꿔서 쓸 수도 있다.

• 결국에 변화할 가능성이 너무 많아서 추천하지 않는다.

• 스타일도 코드리뷰를 하는 이유는 가독성 때문

• 개행도 결국의 제대로 개행을 해놔야 로직 이해가 잘되는 것처럼 사소한 코드리뷰도 중요하다고 생각한다.

• 코드 리뷰의 반은 가독성 때문이다.

• 단위 테스트, 통합 테스트
• 당연히 둘 다 해야된다.

• 컨트롤러를 mockmvc로 서비스를 모킹 하는 단위 테스트와, 의존성을 이용하는 통합테스트가 필요함

• 레포지토리 단위 테스트, 서비스 단위 테스트, 컨트롤러 단위 테스트, 통합 테스트

• view → … → repository 까지 거쳐서 결과가 제대로 나오나 확인 (모든 레이어를 거쳐서 결과가 잘 나오는지 확인하는 테스트)

• 선택사항이다.

• 단위테스트가 훨씬 가볍다(예외를 테스트할 것에 통합테스트라면 시간이 더 오래 걸릴 것이고, 단위테스트면 더 짧게 끝날테니)

• 컨트롤러 단위테스트는 의미가 없다고 생각한다. → 컨트롤러 단위테스트를 할 때 restdocs를 같이 해버린다.

• restdocs의 장점은 테스트로 검증이 가능한 문서라는 것
• API 문서화에는 에러 메시지도 정의가 되어야 한다.

• 예외를 확인하는 테스트가 중요하다.

• 예외 = bug → 나중에 가서 더 어려워진다. (코드 뿐만 아니라 데이터도 바꿔야 할 수 있다.)

• 최대한 많은 예외를 커버할 수 있는 테스트를 보장해줘야 한다.

추가 미션

• MVP1에서 Jacoco 커버리지 80프로이상 유지하기

• 포트폴리오 작성

• 속도를 높여라.
• 백엔드때문에 프로젝트 수행이 늦어질 수도 있다.(남 얘기가 아니다.)

• 테스트 코드 작성때문에, api 작성을 늦춰지지 마라

• 테스크 코드 작성은 경우에 따라 작업자가 유연하게 판단해라