소리치는 아키텍처 - 개발공정 - 인프라 테스트

### 목차
- [(서문) 개발공정](https://ohhoonim.blogspot.com/2024/02/blog-post_62.html)
- [1. 이벤트스토밍](https://ohhoonim.blogspot.com/2024/02/blog-post_47.html)
- [2. 유스케이스 구현](https://ohhoonim.blogspot.com/2024/02/blog-post_92.html)
- [3. 인프라 테스트](https://ohhoonim.blogspot.com/2024/02/blog-post_39.html)  <- 현재문서
- [4. UI 구현](https://ohhoonim.blogspot.com/2024/02/ui_21.html)
## abstract
테스트를 별도의 공정으로 분리하는 개발 방법론들이 대대수다. 공정명에 '테스트'를 포함시킴으로, 코드와 인프라(주로 데이터베이스)에 대한 단위 및 통합 테스트를 수행하도록 상기할 목적으로 공정명을 정하였다. 이 공정은 [[유스케이스 구현]]공정에서 소리치고 있는 [[유스케이스 구현#Port|Port]]에 대한 구현체를 개발하는 공정이면서, 애플리케이션 아키텍처와 Context를 결정하는 공정을 포함하고 있다. 
## tool
- [[유스케이스 구현#tool]] 항목을 포함
- Spring : framework, boot, cloud, security 등 다양한 서브 프로젝트들로 구성되어있으며, 이들 조합만으로 빠른 시간내에 엔터프라이즈급 제품을 생산해낼 수 있다. 
- Docker : 리눅스의 container를 이용하여 가상 환경을 제공해준다. 개발 환경과 운영 환경을 최대한 동일하게 유지 시켜주는 장점이 있다.
- Git : 소스 버전을 관리할 때 사용한다. 분산환경에서 소스 통합에 강력하다.
- Database : 일반적으로 Persistance, Repository 등으로 해석되는 인프라 솔루션들을 총칭한다. Oracle, MySql, PostreSQL 등의 관계형 데이터베이스과 MongoDB로 대표되는 NoSQL 군으로 분류된다.
- 기타 : SMTP, Messaging Servier 등
## activity
- 애플리케이션 아키텍처
	- Auth : 엔터프라이즈급 애플리케이션은 기본적으로 인증/인가 기능을 제공하거나 이용할 수 있는 수단을 제공해야한다. Spring에서는 Spring Security를 통해 다양한 방법을 제공하고 있다. 
	- Context : 애플리케이션의 코드를 실행하기 위한 여러 환경(또는 상황)에 대한 설정을 제공해야한다. DB접속정보 등
- in-port 파라미터 공급
	- in-port 구현체는 [[유스케이스 구현#^7bc277|유스케이스 구현 공정에서 제공]]하고 있으므로  해당 agent에 파라미터를 정확하게 공급하는 것을 목적으로한다.
	- Spring Boot에서는 @Controller 로 표현되는 Bean instance이다. 
- out-port Adaptor 구현
	- [[유스케이스 구현#^e62cc9|out-port]]에 대한 구현 클래스를 바로 작성하지 않고 Adaptor 클래스를 중간에 유지하는 이유는 애플리케이션 간 결합도를 낮추기 위함이다. 
	- 인프라 영역은 데이터베이스 등과 같은 외부 솔루션과의 연계가 주 목적이므로 외부 솔루션이 변경되었을 때를 항상 대비하여야 한다.
## output
### Api
- 사용자는 UI(User Interface)를 통해 애플리케이션을 사용한다. UI가 애플리케이션을 이용하려면 프로그래밍적으로  접근해야 할 것이다. 이 기능을 제공하는 것을 API(Application Programming Interface)라고 부른다. 
- 웹 애플리케이션의 경우 대부분 Rest API라는 방식을 이용하며, 주로 JSON 형태로 데이터를 교환한다.
### Mapper
- 모듈 또는 클래스간 의존성을 줄이기 위해 레이어 아키텍처, 헥사고날 아키텍처 등과 같은 검증된 아키텍처를 이용하게 된다. 이 아키텍처들은 "경계"를 가지고 있으므로 그 경계를 지날때는 전달할 객체(파라미터)를 변환하여 전달해주게 된다. 이러한 변환 객체를 "Mapper"라고 한다. 
- Mapper에 대한 별도 테스트 코드는 작성하지 않는다.
- [VO 그거 꼭 변환해야하나](https://youtu.be/UgaqRs-qTHo?si=vUT-7RXSNnjLrJcV)
### Adaptor
- 유스케이스의 out-port와 인프라간의 Adaptor이다. Adaptor는 주로 데이터베이스가 되는 경우가 대부분이지만 SMTP, Messaging 등이 될 수도 있다. 
### Context 
- 애플리케이션 실행시 사용할 환경 정보이다. 애플리케이션 구현시 실행 arguments로 제공하는 것이 보안상 가장 안전한 방법이지만,
- 보안상 문제가 되지 않는 설정 정보라면 Spring에서는 주로 application.yml 파일에 설정하게 된다. 
- profile을 이용하여 배포환경 별로 구분할 수 도 있다. 
### 단위 테스트 코드
- Api, Adaptor에 대한 단위 테스트 코드를 작성하게 된다. 실제로는 Mock 객체를 잘 활용해야하는 통합테스트 수준의 테스트 코드이므로 예상치 못하게 작성하는데 시간이 오래 걸릴 수도 있다
- 데이터베이스 같은 경우 docker container를 활용한 테스트를 수행 할 수 있다. 
- api, infra에 대한 단위 테스트 : 화이트 -> 블랙 순으로 고려햐여 (유스케이스는 역순)
	- 상세 내용은  [[소프트웨어 테스팅]] 참고
## 구현사례
- [회원가입 api 구축]
- [회원가입 infra 구축]