210726-TIL

Jane·2021년 7월 23일
2

TIL

목록 보기
82/103
post-thumbnail

오늘 한 일

✔️ 더 자바, 애플리케이션을 테스트하는 다양한 방법

  • Mockito
    • Mock 객체는 진짜 객체와 비슷하게 동작하지만 프로그래머가 직접 행동을 관리한다.
    • Mockito는 Mock 객체를 생성, 관리, 검증할 수 있는 방법을 제공하는 프레임워크이다.
    • 단위 테스트
      • https://martinfowler.com/bliki/UnitTest.html
      • 모든 의존성을 끊어야(mocking) 단위테스트라고 주장하는 사람들도 있다.
      • 그러나 단위를 클래스나 객체가 아닌 행동의 단위라고 생각하고, 그 행동과 연관되어 있는 모든 객체들은 하나의 단위라고 생각할 수도 있다.
    • 이미 구현되어 있는 클래스는 Mocking할 필요가 없지만, 외부서비스는 Mocking하는게 좋지 않을까.
    • bang.com 등의 payment 서비스는 테스트 환경을 제공한다.
    • 구현체 없고 인터페이스만 있는 경우
      • 인터페이스를 사용해 구현한 코드가 잘 작동하는지 확인할 때 Mock 객체를 사용할 수 있다.
      • @Mock 애너테이션 붙여주고, MockitoExtension을 클래스 위에 등록해주면 된다.
      • 파라미터에 바로 @Mock을 붙여도 된다.
    • How about some stubbing?
      • when(memberService.findById(1L)).thenReturn(Optional.of(member));
    • verify
      • notify가 1번 호출되었는지 검증
        • verify(memberService, times(1)).notify(study);
      • 어떤 id가 들어와도 validate가 호출되지 않았는지 검증
        • verify(memberService, never()).validate(any());
    • inOrder
      • inOrder().verify(memberService).notify(study);
    • verifyNoMoreInteractions
      • verifyNoMoreInteractions(memberService);
    • BDD
      • 애플리케이션이 어떻게 행동해야 하는지에 대한 공통된 이해를 구성하는 방법
      • given (시나리오 진행에 필요한 값을 설정)
        • import static org.mockito.BDDMockito.given;
        • given(memberService.findById(1L)).willReturn(Optional.of(member));
      • when (시나리오를 진행하는데 필요한 조건을 명시)
      • then (시나리오를 완료했을 때 보장해야 하는 결과를 명시)
        • then(memberService).should(times(1)).notify(study);
        • then(memberService).shouldHaveNoMoreInteractions();
  • assert 키워드
    public StudyService(MemberService memberService, StudyRepository repository) {
        assert memberService != null;
        assert repository != null;
        this.memberService = memberService;
        this.repository = repository;
    }

✔️ [우아콘2020] 수십억건에서 QUERYDSL 사용하기

✔️ Postsquad 스터디

  • Mockito, Querydsl

✔️ Scoup 회의

  • Use case 정의

✔️ 알고리즘

✔️ 파이썬 문법

✔️ 에어비앤비 프로젝트

  • OAuth 로그인 구현 방식 변경

느낀 점

  • Mockito... 어려워보였는데 인강 들으니 별거 아니었다. 바로 프로젝트에 적용가능할 것 같다.
  • Querydsl을 사용할 때 성능적인 측면을 크게 고려하지 않고 사용했었는데 우아콘에서 동욱님 발표를 듣고 많이 반성했다. 이제 무작정 도입 + 한 번 써보기를 넘어서서 성능을 고려하는 개발자가 되고싶다. 전에 짜놓은 코드도 실제 쿼리가 어떻게 날아가는지 보고 개선해봐야겠다.
  • 새리, 프레디와 함께 Use case를 작성했다. 처음에는 프레디가 공유해준 블로그를 보고 액터, 개요, 사전조건, 사후조건, 기본 흐름, 대체 흐름 순으로 작성하려고 했는데, 이렇게 가지 않고 우아한 ATDD에서 인수 조건을 작성한 것처럼 유스케이스 별로 given/when/then을 작성했다. 아직 기획의 일부분에 대해서만 작성했는데 50여개 정도 된다. 미리 use case를 정리해서 공유하면, 서비스에 대한 이해도도 올라가고 파트별로 기획에 대해 다르게 이해하여 발생할 수 있는 문제들도 예방할 수 있는 것 같다.
  • 회의가 늦게 끝나서 알고리즘을 1시간 늦게 풀기 시작했는데 오늘따라 문제가 잘 안 풀려서 3시간에 2문제밖에 못 풀었다. 이제 프로그래머스 level1이랑 level2 중에 쉬운 문제는 다 풀어서 이전처럼 하루에 많이 풀지는 못할 것 같다. 그리고 알고리즘 풀 때마다 느끼지만 python은 내장함수가 참 잘 되어있다.
  • 에어비앤비 프로젝트 때 백엔드에서 Authorization code까지 요청하는 방식으로 OAuth를 구현했었는데 프론트에서 코드를 받아서 백엔드에 보내주는 방식으로 수정했다. 이렇게 하는게 훨씬 자연스럽고, 프론트에서 테스트하기도 쉬운 것 같다.
  • 디디가 배포 자동화에 대해 물어보셔서 아는 선에서 대답해드렸는데 잘 설명드린건지 모르겠다. 프론트이신데 백엔드까지 하시는 것 정말 대단하다. 우아한 테크캠프 나도 가고싶다...나도 프론트하고싶다...

0개의 댓글