개요 특정 조건에 따라 분기하는 기능이 있을 때, 해당 조건에 대한 경계값 테스트를 작성하여 테스트의 신뢰도를 높일 수 있습니다. 경계값 테스트란, 어떤 조건의 경계에 해당하는 값을 테스트하여 특정 조건일 때 기능이 원하는 대로 동작하는지 확인하기 위해 작성하는 테스트입니다. 예를 들어 어떤 물건을 한 번에 주문할 수 있는 수량이 2개라고 했을 때, 2개를 주문하면 주문에 성공하고 3개를 주문하면 주문에 실패하는 테스트를 작성할 수 있습니다. 이와 같이, 테스트를 작성하다보면 동일한 검증 코드에서 여러 값에 대해 테스트를 수행해야 할 경우가 생깁니다. 이번 포스팅에서는 다음의 문자열 검증 유틸 클래스를 통해 @ParameterizedTest에 대해서 설명해보겠습니다. public abstract clas..
🔖 개요 DB에 어떤 값을 저장할 때 전/후처리가 필요한 요구사항이 있을 수 있다. 예를 들어, 사용자의 개인 정보를 암호화해서 저장하는 경우 혹은 데이터베이스에 저장된 값을 불러올 때 Static 한 인스턴스로 변환해야 하는 경우이다. 예시로 작성한 다음의 Entity를 보자. @NoArgsConstructor(access = AccessLevel.PROTECTED) @Getter @Entity public class Member { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private Long id; /* * 1. 데이터 베이스에 저장될 때 암호화 * 2. 데이터 베이스에서 값을 읽어올 때 복호화 * */ private String phon..
🔹 github action - submodule 옵션 일반 git clone이나 git pull 명령어로 슈퍼 프로젝트의 하위에 있는 서브 모듈 코드까지 가져올 수 없다. git clone에는 --recurse-submodule 옵션을 붙여주어야 하고, git submodule update --remote 를 통해 서브 모듈의 변경 사항을 가져와야한다. github action에서도 마찬가지이다. github repository를 checkout 하기 위해서 checkout action을 사용하는데, submodule 에 대한 속성 값을 설정해주어야 서브 모듈까지 checkout 할 수 있다. checkout 에 대한 공식 문서를 보면 다음과 같이 설명하고 있다. - uses: actions/check..
📑 개요 프로젝트에 사용되는 많은 민감 정보들이 있다. 예를 들어, AWS의 서비스와 연동하기 위한 Access Key, JWT의 secret key 와 같은 정보들은 보안상 절대 외부로 노출되어선 안된다. 특히, AWS의 access key를 git public repository에 업로드하게 될 경우 이를 악용하는 사람으로 인해 엄청난 비용을 감당해야 할 수도 있다. 그렇다고 민감 정보를 담고있는 파일만 git에 업로드하지 않고 관리한다면 새로운 서버에 배포할 때마다 민감 정보를 포함한 파일을 일일이 생성해주어야 한다. 또한, 해당 파일에 대한 형상관리도 불가능해진다. 이러한 문제를 git submodule을 통해 해결할 수 있다. git submodule을 통해 민감 정보를 포함한 파일을 submo..
도커는 docker engine 위에서 '컨테이너'라는 단위로 가상 실행 환경을 제공해주는 오픈 소스 플랫폼이다. 도커는 리눅스 커널 위에서 동작하여 가볍고 빠르다는 특징과 이식성, 보안 등 여러가지 장점을 가지고 있는 기술이다. 하지만, 도커는 CRI (Container Runtime Interface) 라는 표준 인터페이스를 지원하지 때문에 쿠버네티스에서 도커에 대한 지원을 중단하는 등 그 위상이 예전같지 않다는 것은 사실이다. 하지만, 현재까지도 많은 서비스와 개발자 사이에서는 도커를 적극적으로 사용하고 있다는 것을 다음의 통계를 통해 확인할 수 있다. 평소, 도커에 대한 관심이 많았기 때문에 관련 문서나 강의를 통해 지속적으로 학습을 이어나가고 있었지만 제대로 정리해야할 필요성을 느끼게 되어 이번..
6월부터 본격적으로 본 과정에 들어가게 되면서, 프로젝트 개발을 위해 필요한 여러 설계를 진행하였다. 그 중에서도 데이터베이스 물리적 설계도 진행하였는데, 담당 멘토님께서 PK를 int 로 잡은 이유에 대해서 여쭤보셨다. 그 이유에 대해 PK 생성 방법을 MySQL의 AUTO_INCREMENT를 사용할 예정이기 때문이라고 답했고 멘토님께서 다시 AUTO_INCREMENT로 PK를 생성하는 이유에 대해 여쭤보셨는데 여기에 제대로 답을 하지 못했다. 단순히, AUTO_INCREMENT 전략을 주로 사용하여 PK를 생성한다는 것은 알고 있었지만 왜 쓰는지에 대해서 깊게 생각해본적이 없었다는 생각이 들었다. 따라서 이번 포스팅에서 PK 생성 전략을 살펴보려 한다. 식별자 (PK) 선택 전략 데이터베이스 기본 키..
