5/16

피드백

DTO는 어디에?

• DTO는 어느 레이어에 속하게 하는 게 좋을까? -> 나는 서비스라고 생각한다. 우르와 페어할 때 DTO가 컨트롤러 레이어에 두게 되면 하위 계층인 서비스에서 상위 계층인 DTO를 참조하게 되는 역류 참조가 발생하므로 서비스에 사용하는 것이 좋다고 생각한다. 이 의견은 DTO가 서비스에서 사용된다는 가정하에 있는 것이기는 하다. 만약 서비스에서 사용하는 DTO가 따로 있다면 기존 DTO는 컨트롤러 레이어, 서비스로 값이 전달될 때 사용하는 DTO를 서비스 레이어에 둘 것 같다.

단위 테스트 중복?

• 레이어별로 만들어놓은 단위 테스트가 같은 기능을 검증하고 있는 것 같다. 컨트롤러 테스트에서 세부적인 비즈니스 규칙을 모두 검증할 필요가 있을까?

-> 검증하고자 하는 대상이 무엇인지에 집중한다.

컨트롤러의 역할은 요청을 받고 응답을 하는 것이다. 비즈니스 규칙의 일부는 검증될 수 있을지언정 컨트롤러의 역할을 검증하는 것이 목표가 되어야 한다. 즉, 컨트롤러 테스트에서는 비즈니스 규칙을 테스트할 필요는 없다고 생각한다.

테스트 피라미드

테스트에서만 사용되는 프로덕션 코드?

테스트만을 위한 프로덕션 코드는 지양하되, 과하게 사용하는 것이 아니라면 제한적으로 허용하자.

Ex. 적절한 생성자가 없는 경우 테스트를 위한 생성자를 추가하는 방법

but, 테스트를 짜기 쉬운 코드를 만드는 것에 좀 더 집중하자.

Spring JDBC with Datasource

Datasource

연결 설정, 쿼리 실행, 트랜잭션 관리에 필요한 메서드들을 인터페이스로 제공하는 틀 애플리케이션과 기본 데이터베이스 사이의 브리지 역할을 한다.

Datasource로 설정할 수 있는 것들

• url
• driver class
• user name & password
• connection pool 설정

Profile

선택적으로 Spring Context를 구성하고, 선택적으로 활성화할 수 있다. 다양한 배포 시나리오에 따라서 변경할 수 있다.

@Profile 로 설정할 수 있다.

application-prod.properties와 application-test.propterties 중에 누가 우선순위가 높을까?

5/19

ATDD

요구사항을 검증하는 테스트로 소프트웨어를 개발하는 프로세스 -> 인수테스트로 소프트웨어를 개발하는 프로세스

ATDD를 하는 이유

생산성 증가

구현 전에 인수 테스트를 수행하는 경우, 팀의 생산성이 두 배가 되었다. -> 작업의 명확한 시작과 끝을 제시한다. -> 빠른 피드백이 가능하다. -> 귀찮은 작업을 프로세스로 강제한다.

Acceptance Test

• 사용자 스토리를 검증하는 기능 검증 테스트
• 소프트웨어 이외 다른 분야에서도 사용되는 용어
• 보통 마지막 단계에서 수행하는 테스트를 의미

테스트 종류

• 단위 테스트
• 통합 테스트
• E2E 테스트
• 인수 테스트 : 사용자 스토리를 검증하는 기능 테스트

인수테스트?

• 인수 테스트는 API 테스트? E2E 테스트? 통합 테스트?

인수테스트는 테스트 의도에 따라 정해지는 것이지 어떻게 구현하는지에 따라 정해지는 것이 아니다. (단위 테스트가 될 수도 있다?)

이번 특강에서 말하는 인수 테스트

• 백엔드 개발자가 단독적으로 적용해서 실천해볼 수 있는 범위
• 고객은 프론트엔드 개발자 혹은 API 활용하는 사람 대상
• API 접점에서 검증하는 E2E 테스트
• API 의 Request와 Response 정보 이외 내부 정보는 최대한 가리는 블랙 박스 형식의 테스트

인수 테스트 만들기

만들기 전에 알아야 할 것

• 블랙박스 테스트 : 인수 테스트는 블랙 박스 테스트의 성격을 가지고 있다. 내부 동작의 구현보다는 시나리오가 잘 동작하는지 확인한다.
• 블랙박스?
  • 클라이언트는 표먼적으로 확인할 수 있는 요소를 바탕으로 검증한다.
  • 실제 사용하는 상황의 시나리오를 바탕으로 요구사항을 작성한다.
  • 내부 구현이나 기술에 의존적이지 않는 블랙 박스 테스트
• E2E 테스트 : 종단간 테스트. API 레벨의 블랙박스 테스트이므로 요청과 응답 기준으로 API 레벨의 E2E 테스트로 검증한다.

인수 테스트 도구 설명

• SpringBootTest
  • ApplicationContext를 쉽게 지정하게 도와준다.
  • 기존 @ContextConfiguration 의 발전된 기능
• webEnvironment
  • MOCK, RANDOM_PORT, DEFINED_PORT, NONE(웹 요청을 안 받는)
• MockMvc

인수 테스트 격리

@DirtiesContext 를 사용하면 컨텍스트를 테스트마다 계속해서 생성한다. 캐시 기능을 사용하지 않게 설정하면 매번 Context를 새로 구성하다보니 시간이 많이 걸린다.

설정이 같으면 캐싱된 컨텍스트를 재사용한다. (MockBean을 사용하는 경우)

DatabaseCleanup : EntityManager를 활용하여 테이블 이름 조회 후 각 테이블 Truncate 수행. ID auto-increment 숫자를 1로 복구시킨다.

인수 조건

• 인수 테스트가 충족해야 하는 조건
• 이번 과정에서는 시나리오 형태로 표현

인수 테스트에서 TDD로 넘어가기

인수 조건을 세우고 -> 이를 검증하는 인수테스트를 만들고 -> 인수테스트를 만족시키는 기능을 구현해도 인정

컨트롤러부터 도메인 방향 -> outside in 도메인에서 컨트롤러 방향 -> inside out 왔다갔다 해도 좋지만 잘 아는 것을 기반으로 모르는 방향으로 진행할 것