[TIL] Today I Lerned - 230106

[TIL] Today I Lerned - 230106

 

230106 기록

 

기록

 

• 설계
• HttpStatus -  NO_CONTENT
• TEST 코드
• Swagger 적용
• 프로젝트 종료 후 KPT

---

설계

 

• 변수명의 차이
  • 설계에 꽤 많은 시간을 들였다고 생각했지만 실제로는 미숙한 부분이 발견
• 메서드 반환 값의 차이와 각 controller와 service 단에서의 반환값 차이
  • 반환값을 정하지 않았기에 개별적으로 반환값을 지정하였고 그에 따라 프로젝트 코드의 통일성이 흐트러지는 경우 발생
• 깃 사용시 해당 경우로 인한 코드 충돌 발생
  • 또한 차후에 코드파일을 하나 만들면서 이름이 통일이 되지 않은 경우 발생
  • 이는 깃에서 올라갈때 문제가 없다가 main 브런치로 지정해서 올리는 순간 코드 충돌발생으로 인한 시간의 소모
  • 겹쳐진 부분에 대한 명확한 해결 경험이 없어서 다수의 팀원들이 본인 브런치에 코드를 올리고 깃에서 재클론을 해오는 등의 시간적 소모가 발생

 

---

HttpStatus -  NO_CONTENT

 

return new ResponseEntity<>("게시글 삭제 성공.", HttpStatus.NO_CONTENT);

 

분명 메시지를 반환해야하는데 반환을 하지 않은 경우

해당 경우에는 해당 기능이 성공했다고 확인을 위해 프로젝트 진행 단계에서는 메시지를 출력할 수 있도록 설계

이때 해당 httpcode를 204로 지정한 것은 삭제 기능의 REST 한 설계를 보여주기 위해 사용한 것

 

그런데 204의 경우 NO_CONTENT로 그냥 코드만 표현하는 것이 아닌 실제로 해당 코드가 들어오면 ResponseEntity의 body를 반환하지 않는다는 것을 알았다.  상태 코드는 해당 코드에 따라 실제 ResponseEntity의 값에 영향을 준다는 것을 알았다. 

---

TEST 코드

 

TEST 코드 -  명확하게 해당 기능에 대해 작성하기

해당 기능 분기에 따라 return하는 값을 시험하고 작동하는지만 확인, 다만 내부로직에서 잘못된 점이 존재하였지만 return값은 정확하게 들어왔기에 그 순간은 캐치하지 못함. 

TEST 코드 작성시 내부 로직은 어떤 방식으로 진행을 하게 될 건지 탐구하는 시간이 필요할 것으로 요망 

 

/***
 * 테스트 코드
 * 1. 상태 검증 : 예상한 값이 나오는지
 * 2. 행위 검증 : 로직이 정확하게 탔는지. 구동했는지 확인하는것
 * verify : assert, 같은 메서드. 해당 메서드를 해당 원하는 동작을 했는지, 흐름을 타는지에 관한 메서드
 *
 * 레이어마다 테스트 코드의 작성이 달라짐
 * 컨트롤러 / 서비스 / 데이터베이스에 대한 테스트 코드가 각각 달라짐
 * 아직은 까다로운 부분.
 * ex : reposi에서 조회할 떄 조회된 데이터 값이 예상한 만큼 잘 들어왔는지 파악하는 테스트
 *
 * 이것들이 단위 테스트
 * test container : 가상 도커 환경 내부에 db서버를 띄우고 sql 파일에 쿼리같은 테스트 가능
 * controller : MOCKMVC - test 단에서 제공 / Autowired로 제공 : 컨트롤러로 들어오는 URL을 실제로 예상한 것처럼 상태코드나 반환값을 파악
 * 이때 Request 값, 요청에 따라 상태코드/값 확인
 * service : Mcck //given / when / then - 데이터를 주고 해당 코드가 잘 돌아가는지 확인
 *
 * 통합 테스트
 * 구현 Test 폴더
 * 실제처럼 돌아감
 * WebTestClient를 활용해서 실제 서비스 ,컨트롤러, 레포지토리
 *
 * 세팅의 힘듬 - 현업에서 돌아가는 서비스들이 다양한 서버를 사용하기에 실제로 통합테스트 세팅을 만드는 것은 하나의 서비스를 만드는것만큼 힘듬
 * 이때 사용하는 것이 Docker
 *
 * 보통 단위테스트에서 끝냄
 * 테스트 코드가 실제 로직이 얼마나 커버를 했는지 - 이 서버의 로직이 얼마나 커버가 가능했는지  -  60만 도달해도 만족
 * 자코코? jacoco , ...etc
 *
 * spring rest docs가 사용
 * 포스트맨 -> 인텔리제이의 환경에서 실행하는 것도 하나의 방법
 */

 

---

 

KPT

• KEEP
  • 팀원들과 주기적인 소통
  • 모르는 것은 공유하면서 같이 성장
  • 디버그 모드와 테스트 코드 그리고 시큐리티 관련 흐름을 잡고 계속 공부하기
• Problem 
  • 확립되지않은 개념 상태에서의 프로젝트 진행
    • 개념을 확립하고 프로젝트를 진행하지 않았기에 생긴 사용과 지식의 괴리감
  • 설계는 끝이 없는 작업
    • 충분한 시간을 들여 설계를 했다고 생각했지만 실제로 미숙한 부분들이 다수 존재
      • 반환 타입 통일
      • 정확한 역할 분배
      • 변수이름, 철자의 차이로 인한 오류 발생
• try
  • 설계
    • 설계부분에 대해서는 시간을 투자하기(양질의 시간 투자)
    • 주어진 시간내에 최대한의 개념을 파악하고 프로젝트에 해당 개념 사용 및 익히기
    • 알고 있는 지식을 활용하기 위한 도전 정신. 
      • 알고는 있지만 나중에 나중에 하면서 사용하지 않았던 빌더, 데이터의 관리등의 기능
      • 차후 프로젝트부터는 해당 개념을 넣어서 진행할 수 있도록 많이 시행하고 오류 해결하기