[NEXTSTEP] ATDD 과정 3주차 피드백, 4주차 시작

2023.07.22 - [공부 기록] - [NEXTSTEP] ATDD 과정 2주차 피드백, 3주차 시작

[NEXTSTEP] ATDD 과정 2주차 피드백, 3주차 시작

 

 

3주차 피드백

• 미션 진행도에 따라 다음주에 하는 것으로 결정

 

 

TDD 관련 설명

• 구간 추가의 경우 List의 index로 넣어 줄 경우 순서가 보장 될까?
  • 된다. 하지만 인수 테스트나 통합 테스트처럼 실제 환경을 가정할 경우 의도대로 동작하지 않을 수 있다.
    • 이럴 경우 따로 index를 위한 컬럼이 필요하다.
      • OrderColumn을 활용 할 수 있지만 성능상 이슈가 발생 할 수 있음
• 단위 테스트 vs 인수 테스트
  • 모든 단위 테스트를 인수 테스트로 작성해야 하나?
    • 인수 테스트는 해피 케이스만 작성하고 이게 통과하면 그 다음부터 사이드 케이스를 검증하는 단위 테스트를 작성하는 TDD 사이클을 돌리는 것을 추천
• (라이브 코딩으로 구간 추가 설명)
  • 요구사항을 구현하면서 단위테스트를 작성하는 것만으로 문서가 될 수 있다.
  • 구현한 이후 중복을 제거하며 리팩터링을 수행

• 토큰을 만들기 위해 멤버 정보를 조회하는 부분에서 구체 클래스를 의존하고 있다.패키지 의존성 제거

• DIP 에서 말하는 유연성이 극대화된 시스템
  • 추상에 의존하며 구체에 의존하지 않는 시스템

https://www.youtube.com/watch?v=dJ5C4qRqAgA

 

 

---

728x90

인수 테스트 리팩터링

• 점진적 리팩터링
  • 인수테스트가 가장 빛을 보일때는 리팩터링 할 때 같다.
  • 인수 테스트 리팩터링
    • 인수 테스트에 대한 궁금증
      • 응답 코드만으로 검증이 되나?
      • 실제 데이터가 저장 되어있는지에 대한 검증이 필요할 수 있지 않을까?
        • 검증의 응답으로 확인
        • 직접 호출해서 확인
          • 스텝이 추가로 필요하다. 테스트 목적은 다르지만 같은 로직을 검증하는 인수 테스트가 발생 할 수 있음
          • 같은 로직이 등장 했을 뿐이지 다른 테스트를 위한 것이기 때문에 중복으로 보지 않음
          • 명시적으로 중요한 테스트라면 각각 만들어서 인수테스트의 의도를 드러내는 것이 더 좋다고 생각함.
      • 인수 테스트의 중복을 허용하지 않는건 아니지만 더 효율적인 방법은 없을까?

• • 인수 테스트 통합
    • 즐겨찾기를 관리한다. 라는 시나리오 하위에 생성, 조회, 삭제 등으로 묶는다.
      • 우려되는 점
        • 하나의 테스트가 많은 것을 검증하는게 아닌가? 테스트를 작성하기 어려워지지 않나?
        • 단위를 어떻게 설정하는 지에 따라 다르게 판단 할 수 있다.
          • 사용자 관점의 기능과 플로우를 인수 테스트의 검증 대상으로 설정
    • Journey Test or Story Test
      • 하나의 기능이 아닌 흐름에 따라 검증하는 테스트
      • API 단위를 벗어나서 하나의 흐름을 단위로 설정하는 테스트
    • 통합 시 장점
      • 테스트 비용 절감
      • 인수 테스트 스텝의 중복을 효과적으로 제거
      • 흐름을 검증 하면서 자연스럽게 사용자 스토리에 대한 검증 가능
      • 사이드 케이스는 단위 테스트에서 수행하게 유도
    • 통합 방법
      • 기존처럼 따로 만든 다음에 하나로 합치기
      • 처음부터 하나의 테스트 메서드로 한 스텝 씩 검증하면서 구현하기

---

 

레거시 리팩터링

• 인수 테스트 있는 경우
  • 기능 변경 혹은 리팩터링을 하더라도 마음껏 할 수 있음
  • 작업하다가 막히거나 꼬이더라도 인수 테스트가 성공한 시점으로 롤백이 가능
• 인수 테스트 없는 경우
  • 인수 테스트를 먼저 만들고 시작
  • 세부 구현에 의존하지 않는 블랙 박스 테스트이기 때문에 구현이 변경되더라도 검증 가능
• 인수 테스트를 만든 이후 스텝
  • 인수 테스트를 성공 시키기 위한 단위 테스트 작성
  • 단위 테스트를 성공 시키기 위한 기능 구현 혹은 리팩터링
  • 단위 테스트 성공 후 리팩터링
  • 반복
• 기존 코드를 바로 수정하면
  • 변경한 부분을 의존하는 부분에서 모두 테스트 실패
  • 인수 테스트가 있더라도 단위 테스트 먼저 검증하고자 하는 부분을 고치고 프로덕션을 수정
• 기존 테스트 코드를 바로 수정하면
  • 코드를 수정하는 것 보다는 좋지만 테스트가 검증하고 있던 프로덕션 코드를 검증 할 수 없게 됨
• 이렇게 고려 할 게 많다면 테스트, TDD는 비효율적인게 아닌가?
  • TDD나 테스트 작성을 꺼려하는 사람들의 가장 큰 이유이고 관리 할 코드가 두배 이상이라 생각하여 번거롭다고 느낌
  • 준비 없이 바로 프로덕션 코드나 테스트 코드를 수정하기 때문이라 생각

---

 

1. 구조 설계하기
   1. 요구 사항에 맞춰 구조를 설계
   2. 확장성을 고려하여 구조를 설계
   3. 설계를 먼저 한 뒤 TDD 사이클이 시작되어야 함
2. 새로운 테스트 만들기
   1. 기존 테스트와 프로덕션 테스트를 그대로 두고 새로운 테스트를 만든다
3. 기능 구현하기
   1. 기존 코드와 중복이 발생 할 수 있음
   2. 기존 코드와 신규 코드가 함께 존재 함
   3. 작업 중 다른 작업을 하더라도 문제 없음
      1. 기존 코드가 있어서 동작에 문제 없고 신규 코드도 남아 있음
      2. 단 기존 코드와 신규 코드가 혼재 되는 기간을 짧게 가져가야 함
   4. 테스트 성공 후 리팩터링
      1. 리팩터링은 테스트 코드가 검증할 수 있는 범위 내에서 시도
   5. 2~4 반복

---

 

테스트 환경과 도구

• 스프링과 직접적인 관련 없는 테스트 환경
  • JUnit5
    • junit-vintage(JUnit4 이하 하위 호환 보장을 위한 모듈)
    • jupiter(Jupiter api로 작성한 테스트 코드를 사용하는 모듈)
    • junit platform
    • @ExtendWith
      • 단위 테스트 간에 공통적으로 사용할 기능 지원을 위한 애너테이션
      • Extension 인터페이스의 구현체를 설정하여 사용 가능
      • ex : MockitoExtension.class
      • SpringExtention.class → JUnit에서 스프링 부트 테스트 기능(컨테이너를 띄울 수 있음)을 활용 할 수 있게 해줌
        • @SpringBootTest 내부에 이 설정이 선언 되어 있다.
• @SpringBootTest
  • 테스트에서 사용할 Context를 구축
  • 스프링 기반 서버 환경을 쉽게 설정할 수 있게 도와줌
  • @SpringBootApplication을 통해 실행하는 서버의 환경과 동일한 설정
  • 스프링빈 전체를 사용하여 테스트 할 수 있음
  • 모든 빈을 사용하기 때문에 어떤 협력 객체를 등록해야 하는지에 대한 고려 를 할 필요가 없음
  • 시간이 상대적으로 오래걸릴 수 있음
  • Slicing을 통해 이를 분할 하여 사용 할 수 있음
    • @WebMvcTest
      • Web과 관련된 부분(Controller 까지)의 기능을 검증 시 @WebMvcTest를 활용할 수 있음
      • 스프링 컨테이너에서 Presentation Layer에 속하는 빈(Controller, Interceptor 등)만 사용
      • 이와 관련된 설정을 손쉽게 도움(@AutoConfigureMockMvc 등)
      • Presentation Layer 외 빈을 참조하는 경우 Mock 객체 설정을 해주어야 하여 번거로울 수 있지만 상대적으로 시간이 짧게 걸림
    • @DataJpaTest
      • Spring Data JPA 사용 시 Repository 관련 빈을 Context에 등록하여 테 스트 시 활용할 수 있게 도와줌
      • 다른 Spring Data를 사용할 수 있음(ex. @DataJdbcTest, @DataRedisTest 등)

문서 자동화 & 테스트

• ATDD 개발 Cycle

• ATDD에 문서화?
  • 요구사항을 작성한 인수 테스트를 구현하는 순서
  • 개발 전 문서화 장점
    • 병렬 작업이 가능
      • 백엔드 개발자간 병렬 작업
      • 백엔드 & 프론트엔드 개발자간 병렬 작업
    • 특히 백엔드 & 프론트엔드 병렬 작업 시 유용함
      • 커뮤니케이션 비용 줄일 수 있음
      • 동작하는 Mock API 생성
• 문서 자동화
  • 문서 자동화란?
    • 문서를 기능과 동기화를 맞추기 어려움
    • 이를 해결하기 위해 코드에서 관리하며 많이 사용하는 도구로는 Swagger와 Spring Rest Docs가 있음
    • Swagger
      • API call 테스트에 특화
      • 스웨거는 기능이 많은 반면 Spring Rest Docs는 단순 문서
      • 불필요한 프로덕션 코드 오염이 발생
    • Spring Rest Docs
      • 테스트 코드에 설정(및 작성)하여 프로덕션 코드에 영향이 적음
      • Http Request를 사용하여 스웨거의 API Call을 대체할 수 있음
      • 테스트를 돌려 Snippit(코드 조각)을 만들고 Asciidoctor를 통해 Adoc 파일을 활용하여 Html 문서를 생성한다.

4주차 미션 소개

• 실습 - 문서화 설정
• 1단계 - 경로 조회 타입 추가
  • 경로 조회 할 때 최소 시간 경로 타입 추가
  • 거리와 함께 소요 시간 정보를 추가
• 2단계 - 요금 조회
  • 경로 조회 시 요금도 함께 나오도록 추가
• 3단계 - 요금 정책 추가
  • 노선별 추가 요금, 연령 별 요금 계산

•