오늘 진행한 것들 🤔

• 토이프로젝트 설계
  • 외부 API를 활용한 커뮤니티 서비스를 클론코딩 하기로 맘을 먹었다.

• 알고리즘 문제풀이
  • 동적 계획법, 해시테이블, 깊이우선탐색 (?) 프로그래머스 / 백준 문제풀이

오늘의 배운 점 🤔

• 토이프로젝트를 설계했습니다.
  • 추억을 살려서 어렸을때 많이 플레이 했었던 던전앤 파이터의 API를 활용한 프로젝트를 진행해보기로 했습니다.
  • ERD를 설계하는데 왜이렇게 테이블이 적지,, 라고 생각했던 순간 외부 API를 쓰기때문에라는 생각이 스쳐지나갔습니다....
  • 이미 만들어져있는걸 얼마나 잘 활용하느냐도 능력이라고 생각하기때문에.. 어떻게 잘 찜쪄먹을지를 많이 고민해봐야겠습니다.
  • 요즘 헤이해지고있다고 생각했었는데 새로운 시작이라고 느껴집니다.
• 알고리즘 문제풀이
  • 동적계획법 문제를 풀이했습니다.
    • 동적계획법은 풀어도 풀어도 어떠한 조건을 설정해서 풀어나가야할지가 가장 큰 고민거리인것 같습니다..
    • 이번에도 다른 유형의 문제를 맞닥트렸을때 매번 어떻게 조건을 설정할지를 못정해서 틀리기 일수였습니다.
    • 문제를 풀때 마음을 급하게 먹지 말아야하는데.. 그게 잘안되는것 같습니다 ㅜ.ㅠ
  • 프로그래머스 2레벨 문제를 풀이했습니다.
    • 처음으로 2레벨 문제들을 풀이를 안보고 풀어보았습니다..
    • 확실히 실력이 늘고있긴 한가봅니다.
    • 마찬가지로 여러 유형중에 학습하지 못했던 알고리즘문제들은 도전조차 못해보는게 아까웠습니다.
    • 이제 새로 프로젝트도 시작했으니 진짜 하루에 2문제만 풀어보아야겠습니다.

오늘 진행한 것들 🤔

• 알고리즘 풀데이

등 몇문제

오늘의 배운 점 🤔

• 오늘은 알게모르게 알고리즘 문제가 풀고싶어서 풀데이로 진행해보았습니다.
• 동적계획법과 분할정복을 활용해 문제풀이를 진행했습니다.
• 오늘의 수확은 그래도 어제보다 동적계획법을 활용하는법을 익힌것 같다는 것입니다.
  • 동적계획법 문제는 대부분 일정한 패턴으로 반복되는 문제가 많았습니다. 
  • 단순히 하루이틀전까지만 해도 문제를 계속 쳐다봐도 이해가 되지 않았는데 오늘은 풀이를 안보고 제출한 문제도 있어서 뿌듯했습니다.
  • 하지만 안풀린 문제들도 많았습니다. 제출까지 했으나 정리조차도 이해가 안가서 올리지 못한 문제들이 존재합니다.
  • 확실히 풀데이는 잘풀릴때는 괜찮지만 안풀리는 문제가 생기기 시작하면 그떄부터 멘탈이 흔들리는것 같습니다.
  • 내일부터는 절대 이렇게 하지 않고 두문제 이상 풀이하지 않으리라.. 다짐을 하게 됐습니다

목표를 지키지 않으니 세우지 않겠습니다.. 🫠

오늘 진행한 것들 🤔

• 컴퓨터 구조 정리

• 토이프로젝트 리팩토링
• 동적계획법 알고리즘 문제 풀이

오늘의 배운 점 🤔

• 컴퓨터구조를 정리했습니다.
  • 하드웨어, 소프트웨어, 응용소프트웨어 이렇게 크게 3구조로 나누는것을 알게 되었습니다.
  • 하드웨어는 말그대로 부품, 소프트웨어는 하드웨어에 의존적인 운영체제 따위를 구동하기 위한 로우레벨 언어로 이루어진 프로그램, 응용 소프트웨어는 흔히 아는 프로그램 같은 것이라고 할 수 있는것 같습니다.
  • 단순히 하드웨어가 한부품 부품이 단독적으로 동작하는게 아닌 시스템 버스를 통해서 이런저런 데이터가 오가는것을 알게 되었습니다.
  • 살짝 MVC 패턴과 비슷하다고 생각했습니다. 단방향 통신을 하는 주소공간 버스와, 양방향통신을 하는 데이터, 컨트롤버스가 모델 뷰 컨트롤러 사이의 요청응답과 비슷하다고 느꼈습니다.
  • 단순히 키보드 키 하나를 눌렀을때에도 상태레지스터, 데이터 레지스터를 확인해서 입력이 된다고 하니, 어느정도 머릿속으로 구조가 그려지는 기분입니다.
  • 폰노이만 구조에 대해서 살짝 공부했습니다.
  • 폰노이만 구조와 하버드 구조의 차이점에 대해서도 살짝 공부하게 되었습니다.
  • 하지만 아직 한번 본것으로는 이해가 안되니 다시 공부해봐야겠습니다.
• 동적 계획법 알고리즘을 활용하여 문제를 풀이했습니다.
  • 풀이를 하다보니 느낀점은 분할정복은 쪼갤 수 없는 부분을 브레이크 포인트로 정한다면, 동적 계획법은 브레이크 포인트를 정하는 대신에 값을 기억해둬 반복 호출을 멈추는..? 그런 정도로 이해가 되었습니다.
  • 관건은 결과값을 얻으려고 풀이를 하는것이 아닌 문제에서 요구하는 답을 구하기 위한 풀이로 사용된다는 점이었습니다.
  • 일반적으로 배열을 사용하는것 같습니다.
  • 다시 글로 정리하면서 생각해보니 이해가 됩니다. 동적 계획법 같은 경우에는 문제의 규칙성을 찾는것  또한 중요한것 같습니다.
• 토이프로젝트 리팩토링을 하였습니다.
  • 기존에 내 댓글이 아닐때 수정이나 삭제버튼이 등장했던 부분에 대해서 단순 if문을 추가하여 비활성화를 시켰습니다.
  • 그리고 게시글과 댓글 삭제에 대한 고민이 생겼었습니다. 데이터를 백업하고 삭제를 하는것이 일반적일지, 단순히 비활성화를 하듯이 삭제 컬럼을 온오프 하는게 맞는것일지에 대한 고민을 해보았습니다.
  • 전자를 redis 로 구현했다가 레디스는 인메모리 데이터베이스라는것이 떠올라 죄다 삭제해버렸습니다.
    • 만료기한을 1년으로 잡고 레디스에 백업 후 삭제하는 로직을 구현했는데, 메모리에 1년동안 저장이라니.. 끔찍한 방법이었습니다.

내일 목표 🤔

• 동적계획법 문제 2문제 이상 풀이
• 가능하면 토이프로젝트 설계하기
• 컴퓨터 구조 정리

오늘 진행한 것들 🤔

• 동적계획법 / 분할정복 정리 (분할정복 응용한 병합정렬,퀵정렬 정리)

• 분할정복/재귀용법 알고리즘 풀이

• 테스트코드 노하우 정리

• 실시간 강의 데이터베이스 수강
  • 각종 실습문제 풀이 (join 과 서브쿼리 활용)

오늘의 배운 점 🤔

• 다이나믹 프로그래밍과 분할정복에 대해서 배웠습니다.
  • 오늘은 뭔가 분할정복 문제를 풀이해보고 싶어서 알고리즘을 5문제나 풀었습니다.
  • 모든 문제를 완벽하게 혼자 힘으로 풀이하지 못했습니다.
    • 재귀용법과 분할정복을 배운지 얼마 되지도 않았는데 어떻게 저 혼자 풀죠? 귀신같이 구현법을 모르겠을때 풀이를 참고했습니다.
    • 하지만 기본적인 로직은 제가 생각했던것과 거의 비슷했었습니다.
    • 처음부터 잘하길 바라면 안되겠습니다. 오히려 오늘같이 풀이하는게 더 이해가 잘되는것 같았습니다.
    • 알고리즘으로 문제를 잘 푸느냐도 중요하지만, 결국 코딩테스트를 준비하는 과정이기때문에 실제로 해당 알고리즘을 실무에서 써먹을 수 있으려면 이해도가 높아야한다고 생각하는데, 급하게 하면 안되겠다는 생각이 들었습니다.
  • 보통 분할정복 문제에서 막혔던 부분은 재귀호출을 어느 부분에서 해야할지가 가장 헷갈렸던것 같습니다.
    • 보통은 쪼개는 부분에서 호출하고, 브레이크 포인트는 더이상 쪼갤 수 없는 부분에서 걸어주면 되는걸 느꼈습니다.
    • 알고리즘 문제도 한마디 한마디 문장을 이해하듯이 풀이하면 더 쉽게 다가오는것 같습니다.
• 데이터베이스 실습문제들을 풀었습니다.
  • 실시간 강의에서 저번주에 배웠던 join 에 이어서 subquery 를 이용하여 원하는 데이터를 가져올 수 있도록 실습문제들을 풀이하였습니다.
    • 보통 어려워지기 시작하는 부분은 테이블들이 복잡하게 얽히기 시작할때 입니다. 조인에 대한 순서보다는 원하는 데이터를 어떻게 조인해야지 한번의 쿼리실행으로 가져올 수 있을지가 관건이었던거 같습니다.
    • inner join 과 outer join 에 대한 차이를 직전 강의때 정리했었는데, 오늘 문제가 등장했었습니다.
      • 바로 두 테이블을 조인했을때, 값이 null인 로우의 갯수를 가져오는 문제였는데, right 조인을 사용하여 풀이하라고 되어있길래 right outer join 으로 조인해 where 로 가져오도록 했더니 쉽게 풀렸습니다.
    • 대체적으로 서브쿼리를 사용해 가져오는것보단 join을 사용해 가져오는것이 머리로도 잘 그려지고 이해가 잘되는것 같습니다.
    • 단순히 각각 겹치는 컬럼을 inner join 으로 조인 후 원하는 조건에 대한 데이터를 가져오는 문제들이 많았습니다.
      • join문에 대한 반복적인 쿼리문 작성은 코파일럿이 도와주긴 했지만, 해당 로직에 대한 구현은 제 머리로 했으나, 강사님께서 어려운 문제라고 극찬을 해주셨습니다.. 기분이 좋았습니다 :D

내일 목표 🤔

• 동적계획법 알고리즘 문제 풀이
• 새 토이프로젝트 설계
• 실시간 강의 컴퓨터구조 수강
• 그룹스터디 인사이트 공유 후 정리

단위테스트는 어떻게 진행될까?

• 사람마다 다를 수 있으나 (?) 기본적으론 gwt (given & when & then)으로 진행된다.
  • Given ⇒ 어떠한 상황이 주어진다.
  • When ⇒ 어떠한 행동을 한다면
  • Then ⇒ 어떠한 행동이 돌아온다.
• 단순히 이렇게 기억하면 쉽다.

사용되는 라이브러리

• 보통 테스트는 비즈니스 로직 단위테스트, 컨트롤러 단위테스트, 리포지토리 단위테스트 이렇게 이뤄지는것 같다.
  • 비즈니스 로직 단위테스트에는 MockitoExtension을 사용한다.
  • 컨틀롤러 단위테스트에는 SpringBootTest 어노테이션을 달고 MockMvc 를 객체로 사용한다.
  • 리포지토리 단위테스트에는 DataJPATest 어노테이션을 달고 테스트한다.
• 단순히 하나하나가 어떠한 행동들을 지원하는지는 나중에 알아보고, 어떻게 테스트해야지 성공적인 결과를 가져올 수 있는지 일단 행동해보자.

비즈니스 로직 단위테스트

테스트 클래스 생성

단순히 테스트 폴더에 테스트 클래스를 생성한다.

spring boot starter test 디펜던시를 추가하면 자동으로 junit 라이브러리까지 사용이 가능하다.

@DisplayName("비즈니스 로직 - 게시글")
@ExtendWith(MockitoExtension.class)
class ArticleServiceTest {

테스트를 원하는 클래스에 MockitoExtension 을 상속받아주고 어떠한 테스트를 진행할 것인지 @DisplayName으로 명시해 준다.

@InjectMocks private ArticleService sut;
@Mock private ArticleRepository articleRepository;

핵심이 되는 서비스클래스를 @InjectMocks 어노테이션을 사용하여 필드변수로 선언해 준다.

sut는 System Under Test 테스트 대상 시스템을 뜻한다.

그리고 해당 서비스 클래스에 주입되어야 하는 Repository 들을 @Mock 어노테이션을 사용해 주입시켜 준다.

(주축이 되는 객체에 주입되어야 하는 객체들을 하나라도 주입시키지 않으면 오류가 발생한다.)

테스트에 사용되는 메서드

• given → 테스트가 진행되는 목업 객체가 가 어떠한 메서드를 호출할 때의 결과를 가정할 수 있다.
  • 리턴값이 있다면 목업 객체를, 예외가 발생해야 한다면 예외를 던져주는 등 상황을 지정할 수 있다.
    • 보통 테스트 대상 시스템의 비즈니스 로직 속 호출되는 메서드들에 대한 리턴값을 지정하는데 쓰인다.

• when & then → 해당 비즈니스 로직을 호출했을 시에 어떠한 결과가 나와야 하는지를 명시한다.
  • when에는 예외가 발생되어야 하는 상황이나 메서드를 호출한다.
  • then 에는 AssertJ 라이브러리를 활용해 assertThat 메서드로 검증을 진행하거나 then() 메소드로 어떠한 메서드를 호출을 했는지 확인할 수 있다.

비즈니스 로직 단위테스트 코드 작성

• 단위테스트 메서드의 네이밍은 given 주어진 것_when 어떠한 행동을 할 때_then 어떠한 것을 하거나 반납한다. 이런 느낌으로 작성해도 좋고, @DisplayName 어노테이션을 사용하여 따로 상황만 명시해줘도 된다.
• 어떠한 행동을 했을 때 대상이 되는 엔티티에 변경사항이 존재하는지, 혹은 엔티티매니저가 어떠한 행동을 실행했는지 에 대한 상황을 가정 후 테스트를 진행할 수 있다.
• 예외가 발생할 때는 Throwable 클래스의 정적 메서드인 catchThrowable()를 이용하여 람다식으로 예외를 캐치해 준다.

@Test
    @DisplayName("댓글 단건 조회시 없는 댓글을 조회하면 예외가 발생한다$")
    void givenNotExistArticleCommentId_whenGetAnArticleComment_thenThrowsException() {
        //given
        given(articleCommentRepository.findById(any())).willReturn(Optional.empty());

        //when
        Throwable throwable = catchThrowable(() -> sut.getArticleComment(1L));

        //then
        then(articleCommentRepository).should().findById(any());
        assertThat(throwable).isInstanceOf(EntityNotFoundException.class);
    }

• 이때의 생각해볼 수 있는 상황들은 무엇이 있을까? 바로 단위테스트를 진행하는 목업 객체의 역할분담이다.
  • 사실 data repository 테스트를 따로 진행한 후 비즈니스 로직 테스트는 단순히 then에 해당 비즈니스 로직이 호출되었는지 를 확인할 수 있다.
  • 하지만 위에 작성해둔 코드로 실행시켜도 문제는 없다. 단순히 해당 계층의 테스트인데 다른 계층까지 점령해도 되느냐의 차이인 것 같다.
  • 더 세분화한다면 Data Repository 테스트 / 비즈니스 로직 테스트 / MVC테스트 이렇게 세분화하여 진행할 수 있지만 결국엔 비즈니스 로직에서는 해당 비즈니스 로직을 호출할 때 모든 repository 메서드를 호출할 것이며, MVC 테스트를 진행할 때도 리퀘스트를 보내면 컨트롤러가 비즈니스 로직을 호출하게 될 것이다.
    • 이에 대한 고민을 할 필요가 있으나, 현재 상황에서는 repository 자체에 여러 커스텀 메서드 (쿼리 dsl을 활용하거나 jpql을 활용해 직접 쿼리문으로 조회하는 메서드)가 존재하지 않기 때문에 비즈니스 로직에서 데이터계층까지 테스트하는 식으로 작성했다.

예외가 발생하지 않는 정상적인 상황에서의 테스트

@Test
    @DisplayName("getArticleCommet() - 댓글 단건 조회")
    void givenArticleCommentId_whenGetAnArticleComment_thenGetsArticleComment() {
        //given
        ArticleComment articleComment = createArticleComment(createArticle(createUserAccount()),createUserAccount());
        given(articleCommentRepository.findById(any())).willReturn(Optional.of(articleComment));

        //when
        ArticleComment.ArticleCommentDto articleCommentDto = sut.getArticleComment(articleComment.getId());

        //then
        then(articleCommentRepository).should().findById(any());
        assertThat(articleCommentDto).isNotNull();
    }

• getArticleComment 메서드의 내용물로는 articleCommentRepository 가 findById로 댓글을 조회한 후 존재한다면 해당 댓글을, 존재하지 않는다면 EntityNotFoundException을 발생시키도록 되어있다.
• given으로 상황을 만들어준다. 모키토는 여러 가지 메서드를 제공해주는데, 그중 any() 는 말그대로 어떠한 상황에서든지 willReturn() 메소드의 매개값을 리턴해준다.
• when은 해당 시점을 뜻한다. 어떠한 메소드를 호출할 때 then에서 검증을 진행한다.
• then에서는 assertThat() 메서드로 어떠한 엔티티를 영속시켰을 때 해당 레포지토리에 저장된 데이터의 수가 +1 이 되었는지 , 혹은 해당 엔티티 객체의 멤버변수에 변동사항이 있는지 까지 테스트가 가능하다.

이렇게만 작성하면 성공적인 테스트 결과를 얻을 수 있다.

이렇게 여러 상황을 지정할 수 있다.

컨트롤러 단위테스트

테스트 클래스 생성

컨트롤러 테스트도 마찬가지로 새 패키지를 생성해 테스트가 진행되는 클래스의 이름뒤에 test를 붙여서 클래스를 새로 생성한다.

여기에 쓰이는 어노테이션은

• @AutoConfigureMockMvc
• @SpringBootTest
• *@Import*(*SecurityConfig*. class)

이렇게 어노테이션을 달아주면 된다.

스프링 시큐리티를 사용 중에 컨트롤러 테스트를 진행하면 시큐리티 설정도 같이 가져와야지 허튼짓을 하지 않고 테스트를 마무리 지을 수 있다.

private final MockMvc mvc;
    @MockBean
    private final SaveFileService saveFileService;
    private final ObjectMapper objectMapper;

    public SaveFileControllerTest(@Autowired MockMvc mvc, @Autowired SaveFileService saveFileService, @Autowired ObjectMapper objectMapper) {
        this.mvc = mvc;
        this.saveFileService = saveFileService;
        this.objectMapper = objectMapper;
    }

이렇게 필드변수로 MockMvc 객체를 주입해 주고, 본인의 입맛에 맞게 주입할 객체를 선언해주면 된다.

생성자에 꼭 Autowired 어노테이션을 달아주자.. 여기에 달아놓지 않으면 오류가 발생한다..

테스트에 사용되는 메서드

• given → 비즈니스 로직 테스트와 마찬가지로 뷰에서 요청이 들어왔을 때 호출되는 메서드에 대한 리턴값이나 상황을 지정해줄 수 있다.
• perform
  • get → GET 요청을 할 때 사용한다.
  • post → POST 요청을 할 때 사용한다. 위에 있는 objectMapper 객체로 dto를 json 형태로 변환해서 매개값으로 전달할 수 있다.
    • contentType → 데이터를 어떠한 타입으로 전송하는지를 명시한다.
    • cotent → 전달하는 데이터를 목업 데이터로 전송한다.
  • put → PUT 요청을 할 때 사용한다. 제공하는 메서드는 post와 같다.
  • delete → DELETE 요청을 할 때 사용한다.
    • 마찬가지로 delete 요청을 보내기 위해 전달되어야 하는 데이터들을 contentType과 content로 정의해 전달할 수 있다.
  • andExpect / andDo → 해당 요청을 보내면 어떠한 응답이 와야 하는지를 명시한다.
    • view → 어떠한 페이지로 이동이 된다든가.. 하는지를 명시한다.
    • model → 어떠한 모델이 attribute 되었는지를 명시한다.
• 해당 메서드만 적절히 잘 사용하면 모든 테스트를 실패 없이 끝낼 수 있다.

컨트롤러 테스트 코드 작성

이전에 신경 써야 하는 부분이 있다.

• 스프링 시큐리티를 적용한 프로젝트인데, 시큐리티 콘텍스트에 담긴 인증정보를 가져오는 메서드가 존재한다거나, authenticatedPrincipal 어노테이션을 사용하는 메소드가 존재할 때의 상황이다.
• 이때를 대비해 @BeforeEach 어노테이션을 사용한 메서드를 선언해 각 테스트메서드 별로 호출 전 상황을 잡아줄 수 있다.
  • 계정을 생성해 놓는다던지, 글을 등록해놓는다던지 할 수 있다.
• 상황을 잡아줬다면 @WithUserDetails 같은 @With~~ 어노테이션을 사용하여 해당 문제를 해결할 수 있다.
• 만약 커스텀 필터를 구현하여 토큰을 사용하거나 하는 상황에서는 따로 어노테이션과 그에 대한 설정 클래스를 생성해 구현할 수 있다.
  • Spring Securit Test 디펜던시를 추가해야 사용이 가능하니 꼭 추가하자.

@DisplayName("[view][GET] 게시글 페이지 ")
    @Test
    public void givenNothing_whenRequestingArticlesView_thenReturnsArticlesView() throws Exception {
        //given
        given(articleService.searchArticles(eq(null), eq(null), any(Pageable.class))).willReturn(Page.empty());
        //when & then
        mvc.perform(get("/articles")).andExpect(status().isOk())
                .andExpect(content().contentTypeCompatibleWith(MediaType.TEXT_HTML))
                .andExpect(view().name("articles/index"))
                .andExpect(model().attributeExists("articles"));
        then(articleService).should().searchArticles(eq(null), eq(null), any(Pageable.class));
    }

• 기본적인 GET 요청을 보냈을 때의 테스트코드이다.
• @DisplayName에 마찬가지로 테스트 상황을 명시한다.
  • 이때 의문점은 메서드의 이름에 given 에 해당 메소드 필드 속 given 메소드의 내용을 명시해야 하는지, 아니면 실제 상황을 명시해야 하는지를 아직 정확히 이해하지 못했다.
• perform() 메서드를 호출해 어떠한 url로 어떠한 요청을 보냈을 때, 어떠한 응답이 올 때 어떠한 것을 반환하는지를 명시해 준다.
• 본인은 then에 해당 url로 요청을 보냈을 때 어떠한 비즈니스 로직이 호출되는지를 명시해 주었다.
  • 해당 부분도 솔직히 정답은 없을 거라 본다.. 각자 프로젝트를 진행할 때 정해둔 규칙에 따라서 작성하면 될 것 같다.

@DisplayName("[view][POST] 게시글 등록 ")
    @Test
    @WithUserDetails("test")
    public void givenArticleInfo_whenSavingArticle_thenSavesArticle() throws Exception {
        //given
        Article.ArticleRequest articleRequest = Article.ArticleRequest.builder()
                .title("haha421")
                .content("haha412")
                .fileIds("")
                .build();
        Article article = createArticle(createUserAccount());
        given(saveFileService.getFileDtosFromRequestsFileIds(any())).willReturn(new HashSet<>());
        given(articleService.saveArticle(any(), any())).willReturn(Article.ArticleDto.from(article));

        //when & then
        mvc.perform(post("/articles")
                        .contentType(MediaType.APPLICATION_JSON)
                        .content(mapper.writeValueAsString(articleRequest)))
                .andExpect(status().isOk())
                .andExpect(content().contentTypeCompatibleWith(MediaType.TEXT_PLAIN));
        then(saveFileService).should().getFileDtosFromRequestsFileIds(any());
    }

• POST / PUT 요청을 보낼 때의 테스트코드이다.
• ObjectMapper 객체를 활용해 json으로 변환 후 전달 할 수 있다.
• given 에는 마찬가지로 해당 url로 요청을 보냈을 때 호출되는 비즈니스 로직 속 또 다른 메서드까지 반환값을 지정해줄 수 있다.

@DisplayName("[view][DELETE] 로그인이 되어있지 않은 상태로 게시글을 삭제하면 BAD_REQUEST를 반환한다.")
    @Test
    public void givenArticleId_whenTryingToDELETEArticle_thenReturnBadRequest() throws Exception {
        Map<String, String> articleId = Map.of("articleId", "1");
        //when&then
        mvc.perform(delete("/articles").contentType(MediaType.APPLICATION_JSON).content(mapper.writeValueAsString(articleId)))
                .andExpect(status().isBadRequest());
    }

• DELETE 요청을 보냈을 때, 예외가 발생하는 상황을 담은 테스트코드이다.

이렇게 각 REST API 별로 상황을 만들어서 테스트가 가능하다.

마무리

테스트코드 작성하는 법을 배워보진 않았지만, 어쩌다 보니 규칙을 알게 되어 제 나름대로 정리해본 글입니다.

제가 직접 실행해보았을 때의 각각의 역할은 어느 정도 알게 되었지만, 해당 메서드들의 원리는 아직 알지 못합니다.

조언해주시거나 고쳐야 할 부분이 존재한다면 댓글 꼭 달아주세요! 감사합니다.

어제의 목표 🤔

• 알고리즘 힙구조/재귀용법 정리하기 ⭕️
  • 기존 실버1수준 까지 풀 수 있던 자료구조 골드 하위 문제 도전해보기  ⭕️ (실버 1문제로 타협)
• 이펙티브 자바 한 챕터 읽고 정리하기 / JPA 한 챕터 읽고 정리하기 (챕터 야바위) ❌(시간부족)
• 게시판 프로젝트 리팩토링 마무리 / 테스트 코드 작성 하고 끝내기 ❌(시간부족)
  • 작성한 코드를 왜 그렇게 작성했는지에 대한 이유를 설명할 수 있어야 할 것 같다. 🤔

오늘 진행한 것들 🤔

• 힙 자료구조에 대해서 정리

• 재귀용법에 대해서 정리
• 힙 자료구조 알고리즘 1문제, 재귀 알고리즘 1문제 풀이

• 데이터베이스 실시간 강의
• 그룹스터디 인사이트 공유

오늘의 배운 점 🤔

• 힙구조에 대해서 배웠습니다.
  • 이진 탐색 트리와 완전 이진 트리의 차이점에 대해서 알게 되었습니다.
  • 이진 탐색 트리는 말그대로 탐색을 위한 구조이고 완전 이진 트리는 최소/최댓값을 빠르게 찾기위한 구조라고 정리했습니다.
    • 완전 이진트리는 값을 무조건 왼쪽 끝 부터 삽입하고 최소/최대 정렬에 따라 부모 노드와 위치를 계속 바꿔가면서 삽입하고 (윗 노드의 값이 자식 노드의 값보다 크거나 같아야 한다 (최대힙일경우)) , 이진 탐색 트리는 부모 노드보다 값이 크면 오른쪽, 작으면 왼쪽 으로 삽입하는것을 알게 되었습니다.
• 재귀용법에 대해서 배웠습니다.
  • 따로 정리라고 할것은 재귀 함수에 어떤 부분에 스탑을 넣을 것인지 조건을 잘 정하는게 관건인것 같았습니다.
  • 자료구조부분은 생각보다 어려웠던 부분도 없었고 이미 구현이 되어있는 api 도 많았지만, 재귀나 정렬부터는 제가 직접 머릿속으로 고민해야될 문제가 많은것 같아서 차분차분 풀어나가야 할 것 같습니다.
    • 멘토님께서 어떠한 문제를 잘 풀게 되는건 알고리즘 풀이의 실력이 늘은것이 아닌 해당 문제에 쓰이는 것에 대한 실력이 상승한거라고 하셨는데, 이제 다시 브론즈부터 풀어나가야 할 문제들이 생긴것 같습니다.
• 알고리즘 문제를 풀었습니다.
  • 재귀 문제는 실버 5로 도전했다가 큰코를 다쳤습니다. 
  • 메소드가 스택에 어떻게 쌓이는지는 이해를 했지만, 직접 풀이를 해보려니 이해가 완전히 되지 않은 느낌입니다.
  • 다시 브론즈부터 풀어봐야겠습니다.
  • 힙 문제는 실버 1문제를 풀이했습니다.
    • 이제 골드문제도 도전해도 되겠다는 생각이 들었습니다. (언제 한번 알고리즘 풀데이를 가져봐야겠습니다.)
• 데이터베이스 실시간 강의
  • JOIN, GROUP BY, HAVING, ALTER ,인덱스 에 대해서 배웠습니다.
    • GROUP BY 같은 경우에는 말그대로 같은 값을 가진 row 끼리 그룹별로 묶어서 관리할 수 있게 해줍니다.
    • 인덱스 같은 경우에는 정리가 더 필요할 것 같습니다.
      • 보통은 pk로 설정해버리면 pk가 되는 컬럼은 자동으로 인덱스가 생성되나, 그렇지 않은 컬럼들도 따로 인덱스를 생성 할 수 있습니다.
      • 따로 제약조건을 붙여서도 관리가 가능했습니다.
    • JOIN 은 이너조인과 아우터 조인이 있으나 이너조인만 배웠습니다.
      • 이너조인은 단순히 두 테이블간 겹치는 부분만 데이터를 가져와서 퍼즐처럼 붙여준다고 이해했습니다.
      • 따로 찾아보니 아우터조인은 중복이 되지 않는 값까지 다 가져와서 중복이 되지 않은 값들을 null 로 입력후 붙여준다고 합니다.
    • having 은 where 과 비슷하지만, having 은 그룹으로 묶었을때의 로우에만 적용되고 where 은 개별 데이터별로 적용된다는 차이점을 갖고있습니다.
    • alter 는 테이블에 변경사항이 존재할때 수정하는 정도의 문법으로 알고있으면 될 것 같습니다.
• 그룹 스터디에서 인사이트 공유를 진행했습니다.
  • 호승님은 네트워크, 컴퓨터구조에 대한 짤막한 정보들을 가져와주셨습니다.
    • 메모리? 의 크기가 작을수록 컴퓨터의 성능이 좋아진다.. 라는 내용이 존재했었습니다. 생각해보니 맞는것 같습니다. 장치 하나하나가 굉장히 작아서 같은 면적에 많이 들어가고 감당이 된다면 그게 최고의 성능을 발휘 할 수 있겠다 생각했습니다.
    • 네트워크같은 경우에는 lan과 wan 의 차이에 대해서 설명해주셨습니다. lan은 제한된 구역내의 네트워크, wan은 광범위한 구역의 네트워크 를 뜻한다고 합니다. 흥미롭네요
  • 이안님은 토이프로젝트를 진행하시면서 겪었던 문제에 대해서 공유를 해주셨습니다.
    • 주변에 누군가가 고민을 하는것을 같이 공유한다는것은 좋은것 같습니다.
      • 저도 그 부분에 대해서 한번 더 생각할 수 있게 되어서 좋았습니다.
      • 주변에 동료가 한계단 한계단 올라가는걸 볼때마다 짜릿한 기분이(?) 듭니다.
  • 진혁님께서는 정적 팩토리 메소드에 대해서 공유를 해주셨습니다.
    • 이펙티브 자바로 정리했던 내용인데 책 자체가 어려워서 솔직히 다시봐도 크게 이해되는 부분은 없었습니다.
    • 하지만 또 다시 보게되니 그 이후로 배웠던 무언가와 연관지어서 생각할 수 있게 되었습니다.
      •  이러한 부분에서 보람을 한번 더 느끼게 되는것 같습니다. 꾸준한 학습이 정답인것 같네요.

내일 목표 🤔

• 알고리즘 정렬/ 공간복잡도 정리하기
• 자료구조 실버 상위문제 2문제 이상 풀이하기
• 이펙티브 자바 반 챕터 읽고 정리하기 / JPA 한 챕터 읽고 정리하기 (챕터 야바위)
• 게시판 프로젝트 리팩토링 마무리 / 테스트 코드 작성 하고 끝내기

내일도 화이팅! 

기존의 주간목표를 작성했던 부분에서 매일 TIL에 일일목표를 작성하는것으로 변경했습니다.

진행했던 것들 🤔

• 알고리즘 정리
  • 시간복잡도 개념익히기
  • 해시 테이블 익히기
  • 트리 구조 익히고 구현해보기
  • 해시/우선순위 큐 문제 풀이
• 스프링 토이 프로젝트
  • 전체 코드 리팩토링 
    • 각 메소드별로 중복된 부분 추출후 함수화
    • 기존 DTO 하나로만 전달하던 것에서 필요한 정보만 주고 받을 수 있도록 Request Response DTO를 사용하도록 수정
    • JPA 공부하면서 DB조회 빈도를 줄일 수 있도록 고민 후 수정
  • 테스트 코드 작성/수정
• JPA 5장,7장,장 정리
  • 연관관계 매핑
  • 고급 매핑
  • 프록시와 연관관계 관리
• 그룹스터디 워크샵 준비
  • 회의/발표 준비/모의발표/ 워크샵 진행

느꼈던 점 🤔

• 이번 한 주는 유난히 힘들었습니다.
  • 매일 먹고자고싸는 시간 제외 머릿속에 코딩생각과 공부생각으로 살아왔는데, 드디어 한계가 온 것 같았습니다.
  • 생각해보니 내가 춤을 그만둔 이유도 너무 춤에 모든것을 쏟아버린 나머지 흥미를 잃어서 그만둔것이었는데, 이렇게 하면 의미가 있나 라는 생각이 들었습니다.
    • 최대한 붙잡아보려 했지만, 주말은 그냥 쉬도록 날렸고, 일단 우선순위가 가장 높았던 그룹워크샵 준비에 힘을 약간 쏟아 부었습니다.
    • 다행히 좋은 결과가 있었던것 같았습니다.
• 마인드셋 특강에서 해당 그래프 얘기가 나온적이 있습니다.

• 지금 절망의 계곡 쯤 온 것 같습니다. 더 열심히 하지 말고 지금처럼 꾸준히만 하자를 목표로 삼아야겠습니다.
• 이제 주간 회고록에서 목표를 TIL을 꾸준히 작성하는 것으로 변경했습니다.  빈도를 늘려서 일간회고를 습관화 해야겠다는 생각이 들었습니다.

좋았던점  🤔

• 오랜만에 정말 아무 생각도 안하고 주말을 잘 보낸 것 같습니다.
  • 요즘 신경쓸게 너무 많았는데도 컨디션이 따라주지 않고, 생각보다 혼자 지내는게 외로웠던 한 주였는데 잘 버틴것 같습니다.
• 힘들어하는 와중에 포기하지 않았습니다. 
  • 하루에 적어도 두시간이상이라도 붙잡았던것 같습니다. 쉴땐 쉬고 놀땐 놀자가 이제 몸에 익은 것 같습니다.
• 그룹 워크샵 발표는 개인적으로 성공적이었다고 생각합니다.
  • 생각보다 설계가 잘되었다고 생각했습니다. 부족한 부분은 계속 보완해나가며 각 역할별로 최선의 결과를 내려고 노력했던 것 같습니다.
• 어렵다고 생각했던 알고리즘에 한걸음 더 다가가게 되었습니다.
  • 남은 힙 자료구조만 정리하게 되면, 제가 알고있는 자료구조에 대한 기본적인 개념은 다 나가게 됩니다.
  • 그런데 생각보다? 해당 자료구조 자체가 어렵다는 생각은 들지 않았습니다.
  • 앞으로 그 자료구조들을 어떻게 찜쪄먹을지에 대한 노하우정도만 익히면 코딩테스트 가 아닌 단순 구현에 어려움은 겪지 않을것 같다는 희망이 생겼습니다.
• 토이프로젝트를 진행하고 리팩토링에 대한 노하우가 살짝 생긴 것 같습니다.
  • 전에는 리팩토링을 한다 할때 겉모습만 바뀌었지 결국 유지보수 하기 쉬운 코드를 작성했다 생각한적이 없었지만 지금은 그래도 관리하기 쉬운 코드를 작성하는 방법을 흉내라도 내는것 같은 착각?이 듭니다.
  • 그 착각을 확신으로 바꾸기 위해서 코딩을 더더욱 습관화 해야겠다는 생각이 들었습니다
    
    • 마찬가지로 알고리즘 문제 하나를 풀더라도 다른사람들은 어떻게 풀었느냐를 참고하는것도 리팩토링 실력 상승에 영향이 있다고 생각이 들었습니다. 
• 드디어 기본적인 토이프로젝트는 끝난것 같습니다.
  • 남의 코드를 보고 참고하는것이 아닌 이제 내 자료를 보고 무언가를 새로 시작할 수 있게 되었습니다.
  • 이래서 문서화가 중요하구나 라는 생각이 들었습니다. 다행히 프로젝트를 진행하는 내내 거의 모든 기능 구현에 대한 글을 남겨놓길 잘했다는 생각이 듭니다. 

아쉬웠던점 🤔

• 현타가 온다면 쉬어야하는데 저는 자책을 하고 있습니다. 내가 개발을 당장 그만둬도 내가 먼저인데. 더 제 자신을 사랑해줘야겠습니다.
• 쉴땐 쉬고 놀땐 놀아라 를 실천하지 못했습니다. 위에는 조금이라도 더 해보려고 노력했다는데, 아닌날에는 쉬어야겠습니다.
• 생각보다 한 주를 돌아보니 아쉬웠다는 생각은 크게 안듭니다. 제가 그동안 열심히 해와서 덜 찔리나봅니다. 유지라도 열심히 해야겠다는 생각이 듭니다.

오늘 진행한 것들 🤔

• 해쉬 자료구조 정리

• 시간 복잡도 정리

• 해쉬 자료구조 알고리즘 문제 풀이

• 스프링 부트 게시판 Article/ArticleComment 도메인 리팩터링
  •  게시글 조회 시에 민감한 정보가 포함되지 않도록 수정 (account dto 제외시킴)

• Article Service 테스트 코드 작성

• 그룹스터디 워크숍 준비 (발표자료 수정 및 모의 발표 진행)

오늘의 배운 점 🤔

• 해쉬 자료구조에 대해서 공부했습니다. 왜 프로젝트 강의에서 강사들이 데이터 저장을 위한 자료구조로 해쉬 셋을 사용하는지 알게 되었습니다.
  • 해쉬 맵을 활용하고 싶은 마음이 생겼습니다. 레디스를 연동시켜보면 될까요? 🤔
  • Repository는 어떤 자료구조로 구현되어있는지 궁금해졌습니다. 한번 찾아봐야겠습니다.
• 시간 복잡도에 대해서 공부했습니다.
  • 사람들이 그렇게 말하던 시간 복잡도가 무엇인지 드디어 알게 되었습니다. 생각보다 어렵지 않았습니다.
  • 시간 복잡도라는 개념을 이해하고 문제를 풀이하니 자연스럽게 해당 코드가 얼마나 오래 걸리지 머릿속으로 그려지게 되었습니다. 🤔
    • 공간 복잡도는 디테일하게 공부하지 못했지만 대충 해쉬 자료구조 같은 것들을 공부하면서 느껴보니 체이닝 기법 같은 오픈 해슁 기법 같은 경우에 메모리 초과가 발생할 수 있겠다..라는 생각이 듭니다. 🤔
• 테스트 코드를 오랜만에 작성해보았습니다.
  • 전에는 Inject Mock과 Mock 이 무슨 역할인지 몰랐으나 지금은 이해가 됩니다. 제대로 알지 못했지만 꾸준히 테스트 코드를 조금씩이라도 작성해온 보람이 있습니다.
  • 하지만 연관관계 맵핑이 되어있는 엔티티에 대해서 테스트코드를 작성할 때 유연하지 못한 느낌이 듭니다. 해당 서적을 읽어봐야겠습니다.
• 리팩터링을 진행했습니다.
  • 기존에 문제라고 생각했던 부분이 있었습니다. 프로젝트 내에서 response request dto를 적극적으로 생성하여 사용하지 않고 dto를 통짜로 사용해왔습니다.
    • 해당 부분에 대해서 조회 부분에는 response를, 삽입 부분에는 request를 사용해 확실히 분리를 해뒀습니다.
    • 전체적으로 코드가 더러웠던 부분 중에 공통부분을 빼버리고 핵심 로직은 최대한 코드의 깊이가 깊어지지 않도록 리팩터링을 진행했습니다. 
      • 이제 누구한테 제 프로젝트를 보여줄 수 있겠다 하는 생각이 들었습니다. (물론 작성해야 하는 테스트 코드가 한 무더기입니다. 🤔
• 그룹스터디 워크숍 발표를 준비했습니다.
  • 자료를 보면서 아직 2달도 안됐지만, 저희 그룹원들이 얼마나 많은 성장을 했는지 , 그리고 저 또한 얼마나 많은 성장을 이뤘는지 다시 한번 짚어보는 시간을 가졌습니다.(물론 제 머릿속으로)
  • 항상 부족하다 생각했는데 되돌아보니 열심히 살아왔고 잘한 거 같아서 좀 쉬어도 되겠다는 생각이 듭니다. 큰일이네요 ;(
  • 모의 발표를 살면서 처음으로 진행해보았습니다. 매번 준비된 거 없이 프리스타일로 춤만 춰오다가 처음으로 가짜 상황극을 해보니 떨렸습니다. 그래도 발표는 잘할 거라 믿습니다. 🤔

내일도 파이팅!