1주차 인수 테스트와 E2E 테스트

0. 배운 사항들

인수테스트란?
- 사용자에게 애플리케이션을 인도할 수 있는지 검증하는 절차 (기능 구현 확인)
  - 사용자 스토리를 검증하는 기능 테스트
  - 사용자 스토리로 테스트할 시나리오 지정
- 이번 과정에서는 API 접점에서 검증하는 E2E 테스트입니다.
인수테스트를 하는 이유
테스트의 종류
- 단위 테스트 - 구현한 부분, 단위를 검증
- 통합 테스트 - 각 단위들이 유기적으로 잘 동작하는지 검증하는 테스트
- E2E 테스트 - 요청과 응답 기준으로 API를 종단하는 테스트
- API 테스트
- 시나리오 테스트
RestAssured를 이용한 인수테스트 작성

1. [실습] 구현단계들

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

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

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

기능 스펙으로부터

인수 조건들 추출
인수 테스트 작성
그에 맞춰서 컨트롤러, 서비스, 도메인 로직 구성해보기
간단한 도메인 로직을 가진 CRUD API를 ATDD 순서에 맞춰서 구현해보기

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단계 - 지하철 인수 테스트 (기능 스펙이 존재할 때)
지하철역 인수 테스트 작성
- 주요 피드백 사항
  - 인수 테스트 가독성
  - 주석 부분에 대한 오류
  - Format 잘 안되어 있음

2단계 - 지하철 노선 관리 (인수 조건이 존재 할 때)
지하철 CRUD
- 주요 피드백사항
  - dto는 어느 layer에서든 사용 가능하게 구현하는 부분이 맞다
    DTO는 가변으로 사용한다.
  - 도메인에서 Setter 같은 객체 메시지를 받는 interface 만들기
  - validation도 있으면 좋다
  - 인수 테스트 가독성

3단계 - 지하철 구간 관리 (기능 스펙만 존재할때)
지하철 노선에 구간을 등록하는 기능을 구현 (조건 + 에러 처리)
- 주요 피드백사항:
  - 기획자와 QA등을 위한 '에러를 표기한다' 를 구체적인 표현으로 표기
  - assertThat(stations).containsExactly(두번째지하철역이름, 첫째지하철역이름, 세번째지하철역이름); 같이 조금 더 구체적인 테스트 검증
  - 개행 컨벤션 및 주석 삭제
  - FirstAddSection 의 잘못된 사용을 우려해서 AddSection으로 리팩토링

Previous요약 및 회고 Next2주차 인수테스트와 TDD

Last updated 1 year ago

1주차 인수 테스트와 E2E 테스트

0. 배운 사항들

인수테스트란?
- 사용자에게 애플리케이션을 인도할 수 있는지 검증하는 절차 (기능 구현 확인)
  - 사용자 스토리를 검증하는 기능 테스트
  - 사용자 스토리로 테스트할 시나리오 지정
- 이번 과정에서는 API 접점에서 검증하는 E2E 테스트입니다.
인수테스트를 하는 이유
테스트의 종류
- 단위 테스트 - 구현한 부분, 단위를 검증
- 통합 테스트 - 각 단위들이 유기적으로 잘 동작하는지 검증하는 테스트
- E2E 테스트 - 요청과 응답 기준으로 API를 종단하는 테스트
- API 테스트
- 시나리오 테스트
RestAssured를 이용한 인수테스트 작성

1. [실습] 구현단계들

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

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

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

기능 스펙으로부터

인수 조건들 추출
인수 테스트 작성
그에 맞춰서 컨트롤러, 서비스, 도메인 로직 구성해보기
간단한 도메인 로직을 가진 CRUD API를 ATDD 순서에 맞춰서 구현해보기

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:
- 주요 피드백 사항
  - 인수 테스트 가독성
  - 주석 부분에 대한 오류
  - Format 잘 안되어 있음

2단계 - 지하철 노선 관리 (인수 조건이 존재 할 때)
지하철 CRUD
PR:
- 주요 피드백사항
  - dto는 어느 layer에서든 사용 가능하게 구현하는 부분이 맞다
    DTO는 가변으로 사용한다.
  - 도메인에서 Setter 같은 객체 메시지를 받는 interface 만들기
  - validation도 있으면 좋다
  - 인수 테스트 가독성

3단계 - 지하철 구간 관리 (기능 스펙만 존재할때)
지하철 노선에 구간을 등록하는 기능을 구현 (조건 + 에러 처리)
PR:
- 주요 피드백사항:
  - 기획자와 QA등을 위한 '에러를 표기한다' 를 구체적인 표현으로 표기
  - assertThat(stations).containsExactly(두번째지하철역이름, 첫째지하철역이름, 세번째지하철역이름); 같이 조금 더 구체적인 테스트 검증
  - 개행 컨벤션 및 주석 삭제
  - FirstAddSection 의 잘못된 사용을 우려해서 AddSection으로 리팩토링

Previous요약 및 회고 Next2주차 인수테스트와 TDD

Last updated 1 year ago

0. 배운 사항들

1. [실습] 구현단계들

2. 배운 사항

A. 요구사항 분석 및 도출

1. 기능 요구사항

2. 프로그래밍 요구사항

3. API 명세

B. Spring 테스트

1. SpringBootTest

2. restAssured

3. JSON Path - DSL && AssertJ

4. 가독성을 위한 꿀팁들

C. 객체 맵핑

D. 패키지 구조

3. 구현 사항들

0. 배운 사항들

1. [실습] 구현단계들

2. 배운 사항

A. 요구사항 분석 및 도출

1. 기능 요구사항

2. 프로그래밍 요구사항

3. API 명세

B. Spring 테스트

1. SpringBootTest

2. restAssured

3. JSON Path - DSL && AssertJ

4. 가독성을 위한 꿀팁들

C. 객체 맵핑

D. 패키지 구조

3. 구현 사항들

1. SpringootTest

1. SpringootTest