[인프런 워밍업 클럽 2기 클린코드&테스트코드] 4주차 발자국

출처: Practical Testing: 실용적인 테스트 가이드

1. 학습 내용 요약

• Persistence Layer

  • Data Access의 역할

  • 비즈니스 가공 로직이 포함되어서는 안됨

  • Data에 대한 CRUD에만 집중한 레이어

• Business Layer

  • 비즈니스 로직을 구현하는 역할

  • Persistence Layer와의 상호작용(Data를 읽고 쓰는 행위)를 통해 비즈니스 로직을 전개

     

• Presentation Layer

  • 외부 세계의 요청을 가장 먼저 받는 계층

  • 파라미터에 대한 최소한의 검증을 수행

• MockMvc

  • Mock(가짜) 객체를 사용해 스프링 MVC 동작을 재현할 수 있는 테스트 프레임워크

• 트랜잭션에 대한 이야기

  • readOnly = true

    • 읽기 전용

    • CRUD에서 CUD 동작 X / only Read

    • JPA에서 CUD 스냅샷 저장, 변경감지 X → 성능 향상

  • CQRS

    • Command와 Read의 분리

    • 두 동작이 서로 영향을 주지 않게 분리

       

       

• Stubbing

  • 컴포넌트를 MockBean 처리하고 동작에 대한 가짜 행위를 정의하는 것

• Test Double

   

  • Dummy

    • 아무 것도 하지 않는 깡통 객체

  • Fake

    • 단순한 형태로 동일한 기능은 수행하나, 프로덕션에서 쓰기에는 부족한 객체

  • Stub

    • 테스트에서 요청한 것에 대해 미리 준비한 결과를 제공하는 객체

    • 그 외에는 응답하지 않음

  • Spy

    • Stub이면서 호출된 내용을 기록하여 보여줄 수 있는 객체

    • 일부는 실제 객체처럼 동작시키고 일부만 Stubbing할 수 있음

  • Mock

    • 행위에 대한 기대를 명세하고

    • 그에 따라 동작하도록 만들어진 객체

     

• 한 문단에 한 주제

   

  • 논리 구조가 들어가지 않는 형태로 구성하는 것이 좋음

    • Parameterize Test

    • 케이스 테스트 코드를 각각 따로 작성

• 완벽하게 제어하기

  • 제어할 수 없는 것들은 상위 계층으로 분리해서 테스트 가능하게

• 테스트 환경의 독립성을 보장하자

   

• 테스트 간 독립성을 보장하자

  • 테스트 간에는 순서가 없어야 함

  • 공유 자원을 사용하는 경우 테스트 간 순서가 생길 수 있음

• 한 눈에 들어오는 Test Fixture 구성하기

  • Fixture

    • 고정물, 고정되어 있는 물체

    • 테스트를 위해 원하는 상태로 고정시킨 일련의 객체

       

  • 중복으로 세팅하는 경우에는 셋업에서 구성을 하면 어떨까

    • 공유 객체를 사용하는 것과 동일한 효과를 가져올 수 있음

       

    • 테스트와 결합도가 생김

    • 코드가 길어지면 의도가 한 눈에 보이지 않을 수 있음

       

  • data.sql 같이 셋업을 다른 파일에 옮기면 픽스쳐의 파편화가 일어날 수 있기에 지양

  • 빌더를 생성할 땐 파라미터에 테스트에서 필요한 것만 남겨놓자

  • 클렌징

    • DeleteAll() Vs. DeleteAllInBatch()

      • DeleteAll()은 각 엔티티를 개별적으로 삭제하며, 삭제 전 select 쿼리를 실행

        • 대신 지우는 순서가 상관없어질 수 있음

        • 물론 항상 되는 것은 아님

      • DeleteAllInBatch()는 단일 쿼리로 모든 데이터를 삭제하여 더 효율적

        • 대량의 데이터를 처리할 때는 DeleteAllInBatch()가 성능상 유리할 수 있음

           

• @DynamicTest

  • 어떠한 시나리오를 기반으로 상태를 공유하면서 테스트를 진행할 수 있음

• 테스트 환경 통합

  • 테스트 환경을 통합하여 테스트 성능 최적화

  • 환경이 다르면 서버가 테스트마다 새로 떠야함

     

     

• Rest Docs Vs. Swagger

  • RestDocs

    • 장점

      • 테스트를 통과해야 문서가 만들어짐 (신뢰도 증가)

      • 프로덕션 코드에 비침투적

    • 단점

      • 코드 양이 많음

      • 설정 어려움

  • Swagger

    • 장점

      • 적용이 쉬움

      • 문서에서 바로 API 호출을 수행해볼 수 있음

    • 단점

      • 프로덕션 코드에 침투적

      • 테스트와 무관하기 때문에 신뢰도가 떨어질 수 있음

2. 미션 회고

• Day 15. Layered Architecture 구조의 레이어별 특징을 정리하고, 어떻게 테스트 하면 좋을 지 정리하는 미션이었다. Persistence Layer, Business Layer, Presentation Layer 역할에 대하여 다시 정리해보고, 레이어의 특징에 따른 테스트 코드 예시를 정리해볼 수 있는 기회였다.

  • 미션 링크: https://www.notion.so/Day-15-1275cf1d569e8067b43ef2245e1f74ec

• Day 18. @Mock, @MockBean, @Spy, @SpyBean, @InjectMocks의 차이를 정리하고, 주어진 테스트 코드를 리팩토링하는 미션이었다. 강의 시간에 다루었던 어노테이션들에 대해서 자세히 알아볼 수 있었다. 또한, 코드를 리팩토링하며 강의에서 배웠던 내용들을 응용해 볼 수 있었다.

  • 미션 링크: https://www.notion.so/Day-18-12a5cf1d569e804e8012f4021394b5bd

     

3. KPT

• Keep

  • 시험 기간이 겹쳤지만, 과제와 진도를 밀리지 않고 잘 수행하였다.

     

• Try

   

  • 학습했던 내용들을 앞으로 잘 활용하여, 한층 더 성장한 개발자가 되어야겠다.

4. 느낀점

• 4주간의 워밍업 클럽 일정이 마무리되었다. 처음 워밍업 클럽을 알게 되었을 때, 테스트에 대해 깊이 있게 학습할 수 있는 좋은 기회라고 생각하여 신청했다. 그러나 클럽 활동을 통해 다양한 지식과 기술을 배울 수 있었을 뿐만 아니라, 다른 참가자들의 코드와 질문들을 보면서 새로운 시각을 갖게 되고, 많은 자극을 받을 수 있었다. 다음 워밍업 클럽이 열린다면, 한번 더 참가하고 싶다.