본문 바로가기

분류 전체보기

Mock VS Stub VS Spy Mock 반환값이 없는 함수를 테스트할 때, 특정 객체에서 특정 함수가 호출되었는지 테스트할 때 사용한다. Stub 특정 객체에서 특정 함수를 호출할 때, 특정한 값이 반환되라고 더미 데이터를 지정할 때 사용한다. Spy 특정 함수만 실제 함수를 호출하게 하고 싶을 때 사용한다. mocking을 사용할 때, 세가지의 역할이 구분되지 않아 마구 섞어쓰게된다. 그런데 각자 용도가 다르기 때문에 한번 생각해보고 쓰자.
gradle build와 Jenkins gradle java plugin을 사용하면, build 명령문 실행 시, gradle에서 task check 함수를 실행한다. 그래서 단순히 gradlew build 명령문으로 build를 하는 경우, 테스트에 실패해도 젠킨스에는 build 실패로 뜨게 된다. 이렇게 build / test 단계를 나눠서 구성하는 경우, build 단계에 check 명령문을 제외 (-x)하겠다는 옵션을 추가해줘야한다. 그러면 Build 단계에서 테스트를 실행하지 않는다. gradlew build -x check 참고 https://proandroiddev.com/understanding-gradle-the-build-lifecycle-5118c1da613f https://www.testmo.com/guides/jenki..
개발자를 위한 최소한의 네트워크 지식 방화벽 방화벽은 미리 정의해둔 보안 규칙에 의해서 들어오고 나가는 네트워크 트래픽을 모니터링하고 제어하는 역할을 한다. VIP 가상 IP (Virtual IP)의 약자이다. NAT 사설 네트워크에 속한 여러 호스트가 하나의 공인 IP으로 인터넷에 접속하기 위해 사용하는 기술을 말한다. NAT은 제한된 공인 IP을 여러 호스트가 공유해서 사용하기 위해 나온 기술이다. 그래서 공인 IP를 NAT IP이라고 부르기도 한다. 인바운드 트래픽 인바운드 트래픽은 외부에서 서버 내부로 들어오는 요청을 말한다. 인바운드 트래픽 IP 제한은 서버를 호출할 수 있는 외부 서버 IP를 관리하는 것을 말한다. 아웃바운드 트래픽 아웃바운드 트래픽은 서버에서 외부로 나가는 요청을 말한다. 즉, 서버에서 다른 외부 서버를 호출하는..
IPv6와 Nginx Ipv4 ipv4 프로토콜은 우리가 익히 알고있는 32bit의 IP 주소 체계로 되어있다. 그러다보니 사용할 수 있는 IP 수가 43억개로 제한되어있다. 223.130.195.95 Ipv6 Ipv6 프로토콜은 Ipv4 인터넷 주소가 고갈되는 문제를 해결하기 위해 만들어졌다. Ipv6은 128비트로 되어있고, IPv4 주소공간에 비해 296배의 크기를 갖는다. 2001:0db8:85a3:08d3:1319:8a2e:0370:7334 요상하게 생겼는데, 이게 주소다. nginx에서 Ipv6 활성화하기 nginx.conf 파일에서 listen 80; 하위에 다음과 같이 선언해주면, nginx에서 ipv6 주소 요청을 수신할 수 있다. listen [::]:80; 이 설정은 서버에서 ipv6을 활성화한 상태에서만..
[EDA] 이벤트 발행하기 애플리케이션에서 이벤트를 발행하는 방법은 크게 Application layer event와 Persistence layer event으로 나뉜다. Application layer event 애플리케이션 안에서 명시적으로 이벤트를 발행하는 방법이다. 장점은 원하는 시점에 이벤트를 발행할 수 있다는 것이다. DB에 데이터가 적재되지 않는 상황에서도 이벤트를 발행할 수 있다. 단, 도메인과 DB가 명시적으로 분리되어있는 경우에만 사용가능하다. 만약 도메인과 DB를 다른 애플리케이션에서 사용하고 있는 경우, 이벤트를 감지하지 못하는 상황이 발생할 수 있다. Persistence layer event 데이터 저장소를 활용하여 이벤트를 발행하는 방법이다. CDC가 대표적인 예이다. 이 방법은 도메인/DB가 분리되어..
좋은 API 설계하기 규칙 항상 사용자를 생각하기 설명서 작성하기 (api docs) 성공 / 실패 응답 모델을 모두 준비하기 명사만 사용하기 안티패턴 : /get-user, /add-user /delete-account 명확하고 직관적인 이름 사용하기 명확한 사례가 아니면 축약어 사용하지 않기 /identification-numbers보다는 /ids가 명확하다. 소문자만 사용한다. 단어는 -(하이픈)으로 구분한다. 특수문자는 사용하지 않는다. 파라미터는 카멜케이스를 사용한다. API version을 제공한다. /v1/account 혹은 header parameter: X-API-VERSION 좋은 API 설계 사례 Stripe (online payment system): https://stripe.com/docs/api T..
[EDA] 이벤트 데이터 설계 이벤트 설계 이벤트는 “뭔가" 일어났음을 전하는 메시지가 아니라, 이벤트가 발생한 동안의 모든 일들을 기록해야한다. 이 출력 이벤트를 단일 진실 공급원으로 간주해서 다운스트림 컨슈머가 소비할 불변의 팩트로 기록해야한다. 때문에 컨슈머는 이벤트 데이터 만으로도 데이터를 처리할 수 있다. 이론적으로는 출력 이벤트를 SSOT으로 간주하라고 한다. 그러나 실제 서비스에서는 ZERO-PAYLOAD 방식을 사용하는 경우가 많은 것 같다. 이벤트 스트림에는 하나의 논리적 이벤트를 나타내는 이벤트가 포함되어야 한다. 이벤트 데이터 타입은 가장 좁은 범위를 사용한다. 이벤트는 하나의 목적만 가진다. 다용도 스미카는 비즈니스 요건이 조금만 달라져도 엄청나게 복잡해진다. 이벤트 크기는 최소화한다. 이벤트 메시지가 큰 경우,..
Transactional outbox Transactional outbox은 MSA 환경에서 이벤트 메시지 발행을 보장할 때 사용하는 패턴이다. 이벤트 메시지 발행 시점 애플리케이션에서 이벤트를 발행할 때에는 트랜잭션 내부 혹은 외부에서 호출하는 상황에 따라 장단점이 있다. (1) 트랜잭션 안에서 메시지 발행 메시지 발행 여부를 쉽게 보장할 수 있다. 그러나 메시지 발행의 실패가 곧 전체 서비스로 장애가 전파될 수 있다는 단점이 있다. (2) 트랜잭션 밖에서 메시지 발행 메시지 발행 실패가 즉시 해당 서비스의 장애로 전파되지 않는다. 그러나, 메시지 발행에 실패해도 메시지 발행을 재시도 할 수 없다는 단점이 있다. 위의 방안은 모두 안정적으로 메시지 발행을 보장할 수 없기 때문에 다른 대안이 필요하다. 메시지 발행 보장하기 Transacti..

티스토리툴바