3주차 Association

0. 배운 사항들

• 인수테스트란?

  • 사용자에게 애플리케이션을 인도할 수 있는지 검증하는 절차 (기능 구현 확인)

    • 사용자 스토리를 검증하는 기능 테스트

    • 사용자 스토리로 테스트할 시나리오 지정

  • 이번 과정에서는 API 접점에서 검증하는 E2E 테스트입니다.

• 인수테스트를 하는 이유

• 테스트의 종류

  • 단위 테스트 - 구현한 부분, 단위를 검증

  • 통합 테스트 - 각 단위들이 유기적으로 잘 동작하는지 검증하는 테스트

  • E2E 테스트 - 요청과 응답 기준으로 API를 종단하는 테스트

  • API 테스트

  • 시나리오 테스트

• RestAssured를 이용한 인수테스트 작성

1. [실습] 구현단계들

1단계 - OneToMany (FetchType.Eager)

2단계 - Lazy Loading By Proxy

3단계 - One To Many (FetchType.Lazy)

2. 배운 사항

A. 요구사항 분석 및 도출

1. 기능 요구사항

• 기능/ 프로그래밍/ API 명세로 나눠서 요구사항을 받았을 때, 계층 별로 도메인 로직, 코드레벨, 인터페이스 로직들을 정확히 어떻게 구현해야 될지 알 수 있었습니다.

• 테스트되어야 할 기능 목록들을 의미하며 도메인 로직들을 이야기합니다.

• 요구사항에서 인수조건들(Given, When, Then)을 도출합니다.

2. 프로그래밍 요구사항

• 재사용성, 가독성, 테스트의 격리 등 테스트에 대한 원칙들을 지키면서 구현하기

• 패키지 구조, 의존성 관리 등 보이지 않는 규칙을 세워서 지키면서 구현하기

• 객체지향적인 코드(객체지향 생활체조)라는 원칙들로 코드에서 bad smell이 나지 않게끔 구현하기

3. API 명세

• DTO와 컨트롤러 레벨에서 어떤 값을 받고 어떤 값을 반환하는지 알 수 있었습니다

  • Controller

    • @PathVariable

    • @RequestBody

    • @GetMapping

    • HTTP 응답 코드

  • DTO

    • Request 형태

    • Response 형태

    • 가변과 불변 DTO 장단점

    • DTO에서 Entity를 의존하지만 그 반대는 좋지 않은 의존성

B. Spring 테스트

1. SpringootTest

• Context를 테스트마다 bean들을 주입해서 생성합니다.

• 에노테이션들

  • 환경에 대한 설정

    • @SpringBootTest - 클래스, 메서드에 명시(Context 지정)

      • @LocalServerPort - 컨텍스트의 지정 포트

      • @DirtiesContext - 클래스(매 테스트마다 초기화(시점변경가능))

  • 편리성을 위한 애노테이션

    • @BeforeEach - 테스트 실행 마다 필요한 이전 세팅들

  • 가독성을 위한 애노테이션

    • @DisplayName - 테스트 실행 시 나타나는 이름으로 명시됨

      • @Nested - 테스트간의 그룹관계를 나타냄 (예: 오류 발생시, 성공시나리오)

  • 테스트 명시

    • @Test

2. restAssured

• RestAssured의 사용법을 익혔습니다.

 ExtractableResponse<Response> response =
            RestAssured
                .given()
                    .log().all()  // Request에 대한 로그 레벨 설정
                    .body(params) // Request의 형태
                    .contentType(MediaType.APPLICATION_JSON_VALUE)
                .when()
                    .delete(String.format("/stations/%s",id))
                    .post("/stations") // request로 대상 경로 와 http 메서드 지정
                .then()
                    .log().all()
                .extract();
                

3. JSON Path - DSL && AssertJ

• JsonPath를 사용해서 response를 추출하였습니다.

responseStations
    .jsonPath()
        .getList(".").stream().count() // 갯수 추출

• AssertJ 같은 메서드를 사용하였습니다.

  • assertThat()

  • doesNotContain()

  • containExactly()

assertThat(response.statusCode()).isEqualTo(HttpStatus.OK.value());
assertThat(response.jsonPath().getString("name")).isEqualTo(신분당선);
assertThat(response.jsonPath().getString("color")).isEqualTo(BG_RED_600);
assertThat(response.jsonPath().getList("stations.name")).contains(첫째지하철역1, 두번째지하철역1);

4. 가독성을 위한 꿀팁들

• 용어의 통일성

• Step으로 분리하기

• 매직넘버 선언하기

• formatter 잘 사용하기

C. 객체 맵핑

• JPA 일급콜렉션 사용하기

• db 스키마와 객체 맵핑

• 패키지 구조

D. 패키지 구조

• CQRS

• 기능 단위 분리

• 도메인 단위 분리

3. 구현 사항들

• 1단계 - 지하철 인수 테스트 (기능 스펙이 존재할 때)

• 지하철역 인수 테스트 작성

• PR: https://github.com/next-step/atdd-subway-map/pull/813

  • 주요 피드백 사항

    • 인수 테스트 가독성

    • 주석 부분에 대한 오류

    • Format 잘 안되어 있음

• 2단계 - 지하철 노선 관리 (인수 조건이 존재 할 때)

• 지하철 CRUD

• PR: https://github.com/next-step/atdd-subway-map/pull/866

  • 주요 피드백사항

    • dto는 어느 layer에서든 사용 가능하게 구현하는 부분이 맞다

      • DTO는 가변으로 사용한다.

    • 도메인에서 Setter 같은 객체 메시지를 받는 interface 만들기

    • validation도 있으면 좋다

    • 인수 테스트 가독성

• 3단계 - 지하철 구간 관리 (기능 스펙만 존재할때)

• 지하철 노선에 구간을 등록하는 기능을 구현 (조건 + 에러 처리)

• PR: https://github.com/next-step/atdd-subway-map/pull/961

  • 주요 피드백사항:

    • 기획자와 QA등을 위한 '에러를 표기한다' 를 구체적인 표현으로 표기

    • assertThat(stations).containsExactly(두번째지하철역이름, 첫째지하철역이름, 세번째지하철역이름); 같이 조금 더 구체적인 테스트 검증

    • 개행 컨벤션 및 주석 삭제

    • FirstAddSection 의 잘못된 사용을 우려해서 AddSection으로 리팩토링