### 목차
- [(서문) 개발공정](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 구축]
Session 대신 JWT를 사용하는 이유 실 서버는 하나의 인스턴트로만 동작하지 않는다. 서버의 고가용성(high availabliity, HA)을 확보하기 위해 두 개 이상의 병렬서버로 운영하게 된다. 서버가 병렬로 운영되는 상황에서 세션을 사용하면 각 서버간의 세션을 동기화하는 문제가 발생한다. 이를 해결하기 위해 공유 데이터베이스를 이용한 세션공유 기법들을 사용하기도 한다. 서버가 많아지면 세션동기는 더 어렵다. JWT를 사용하면 세션사용으로 인한 서버 자체에 부담도 줄이면서 공유 세션에 대한 관리가 한층 수월하다. 스프링 시큐리티 - SecurityConfig.java session을 사용하지 않도록 설정 jwtAuthFilter 추가 httpBasic 제거 - JwtAuthenticationFilter.java config.filter 패키지에 파일 추가 jwt dependency 추가 (3개). gradle refresh하는 거 까먹지 말기 config.service 패키지에 [JwtService.java](http://JwtService.java) 추가 jwtService와 UserDetailService final field 추가. @RequiredArgsConstructor 까먹지 말기 - config.service.JwtService 소스 참조해서 파일 작성 - controller, service 수정 User 를 리턴하면 pwd가 그대로 노출되므로 AuthResponse와 AuthRequest로 교체 Github https://github.com/ohhoonim/factory.git 유튜브 영상 스프링부트 - 보안 JWT JWT - refresh 토큰과 logout
``` [!NOTE] Winddows와 Macos macos를 기준으로 설명하고 있으나, 거의 대부분 macos의 `Cmd`키를 `Ctrl`키로 변경하면 windows에서도 그대로 사용할 수 있음 ``` # VSCode 단축키 - `Cmd + p` : 파일 오픈을 위한 palette - `Cmd + shift + p` : 명령어 실행을 위한 palette. `Cmd + p` 한 다음 '>'를 입력해도 됨 - `Cmd + shift + o` : 현재파일에서 심볼 찾기 (field, method, function 등). `Cmd + p`한 다음 '@'를 입력해도 됨 - `Cmd + Opt + ` : 열려있는 편집기 전환 - `Cmd + shift + e` : 편집기와 탐색기를 전환 함. (탐색기에서 vim 커서 이동 키도 동작한다는 것이 핵심) - `Cmd + Opt + ` : 열모드로 블럭 지정. (VIM단축키와 조합하면 최상임. 이건 글로 설명이 안됨) --- ``` [!NOTE] VSCode용 Vim 확장 - 여기서는 vscodevim 에서 제작한 Vim 확장을 설치하여 사용한다. Vim 단축키는 다를 바 없다. - `esc`키를 눌러 Normal모드 진입시 '한글' 입력상태인 경우 많이 불편하다. '한영'을 자동으로 변환해주는 여러 방법들을 써봤지만, 몇 일 지나면 풀려서 잘 동작 안한다. 그냥 Normal 모드 진입시 '한영'변환을 신경써서 잘 해주자. (시간낭비하지 마세요) - macos의 경우 `Cmd`키와 `Caps`키를 바꾸자. - Windows의 경우 `Ctrl`키와 `Caps`키를 바꾸자. (써보면안다. 얼마나 편한지) ``` ``` [!warning] - 표기된 모든 단축키는 `대소문자`를 구분합니다. (shift 입력하기 귀찮아서임) - `잘라내기`라고 표기한 것은 `붙여넣기`가 가능하다는 뜻입니다. - VIM 모드 전환은 직...
설치하기에 앞서 테스팅 이야기 ISO/IEC/IEEE 29119 에서는 소프트웨어 테스팅의 표준standard에 대해 정의하고 있습니다. 돈받고 파는 문서를 '표준'이라고 번역하기는 좀 껄끄러운데요. 'standard'는 비지니스를 안정적으로 수행할 수 있는 잘 정리된 '가이드' 정도가 올바른 번역이 아닐까 생각됩니다. 소프트웨어에 표준이 있다면 얼마나 좋겠습니까마는 no silver bullet 이라는 말도 있듯이 이건 그냥 iso에서 제시하는 가이드일 뿐이라는 것이 개인적인 의견입니다. 뭐 대단한거 한다고 시작하는데 말이 많군요. (^^;) 29119 part2에서는 테스트프로세스를 다루고 있구요. 이 중 test management process 항목이 있습니다. 어딜가나 비지니스가 끼어드니 management는 빠지는 곳이 없네요. 먹고살려면 어쩔수 없죠. 경영진을 설득하기 위한 부단한 연구라고 인정하는 수밖에. 출처 : http://softwaretestingstandard.org/part2.php 테스팅 서버를 구성하는 이유는 test management process 관점에서 'test monitoring & control'이 필요하기 때문입니다. (위 그림에서 가운데 노란색 박스) testlink 는 오픈소스로서 전 세계에서 가장 많이 사용되고 있는 툴이며 monitoring과 control을 위해 적절한 기능을 제공하고 있다고 판단됩니다. 맨티스는 testing completion 조건을 만족시키기 위한 테스팅 조직과 개발 조직간의 협업툴로서 이용될 수 있습니다. 개발조직에서는 맨티스와 같은 버그 리포트 툴을 사용하고 있으며 bugzilla, jira와 같은 다른 버그리포트 툴로 대체될 수 있습니다. 본 포스팅에서는 monitoring & control 을 수행하기 위한 테스팅 환경 구축이라고 보시...
댓글
댓글 쓰기