멋쟁이개발자

| @SpringBootTest 란?full application config을 로드해서 통합 테스트를 진행하기 위한 어노테이션설정해놓은 config, context, components를 모두 로드DataSource bean을 그대로 사용하기 때문에 in-memory, 로컬, 외부 상관 없이 DB를 사용해서 테스트가 실행테스트할 때마다 DB가 롤백되지 않기 때문에 @Transactional을 추가 필요SpringBootTest 가 포함하는 annotation@Target(value=TYPE)@Retention(value=RUNTIME)@Documented@Inherited@BootstrapWith(value=SpringBootTestContextBootstrapper.class)@ExtendWith(v..

테스트 코드와 TDD란?💡 TDD vs BDD 개념설명 영상tv.kakao.com/channel/3693125/cliplink/414004682 | 단위 테스트를 하는 이유?우리는 개발이 끝난 뒤에 문제가 없는지 확인하기 위해 애플리케이션을 실행하고, 직접 수동 (통합) 테스트를 진행해야 한다.통합 테스트를 위해서는 캐시, 데이터베이스 등 외부 컴포넌트들과 연결 등 부가적인 시간이 필요하고, 여러 모듈이 연계된 상황에서 디버깅을 해야 하기 때문에 시간 효율도 낮아진다.그러므로 우리는 개발 및 테스팅에 대한 비용을 줄이기 위해 통합 테스트 전에 단위 테스트를 작성해야 한다.| 단위 테스트 vs 통합 테스트단위 테스트(Unit Test)하나의 모듈을 기준으로 독립적으로 진행되는 가장 작은 단위의 테스트여기..

`좋은 테스트 코드`와 `테스트하기 좋은 코드`테스트 코드의 중요성은 모두가 잘 알고 있습니다.하지만 실제로 테스트의 `가성비`에 대해서는 종종 의문을 가지게 됩니다.모든 코드를 테스트해야 할까?테스트 작성이 이 코드에 정말 필요한가?결국, 테스트하기 좋은 코드를 어떻게 판단할지에 대한 고민으로 이어집니다.이번 글에서는 테스트하기 좋은 코드와 테스트의 비용에 대해 살펴보겠습니다.| 테스트하기 좋은 코드란 무엇인가?테스트하기 좋은 코드를 판단할 수 있는 몇 가지 기준이 있습니다.이를 통해, 어떤 코드에 대해 테스트를 작성해야 하는지 명확히 이해할 수 있습니다.1. 복잡한 코드코드만 봐서는 동작을 이해하기 어렵거나, 예상 가능한 버그가 숨어 있을 가능성이 높은 코드.ex) 조건문이 많거나, 여러 상태가 얽혀..

성능 테스트로 병목구간을 확인하고, 해소해보자기존에 구현한 `콘서트 예약 서비스` 프로젝트에 대해 K6로 부하테스트를 진행하여, 부하지점을 찾아 병목의 원인을 찾고 개선해보고자 합니다. | 부하 테스트(Load Testing)란?서비스가 특정 조건에서 얼마나 잘 작동하는지 평가하기 위한 성능 테스트 기법실제 사용자 환경과 유사한 부하를 인위적으로 생성해 시스템의 처리 능력, 응답 시간, 안정성을 측정특히 고부하 상황에서 병목 현상을 찾아내고, 시스템의 한계를 파악하는 데 중요한 역할을 함 부하 테스트의 목적성능 병목 현상 발견 : CPU, 메모리, 네트워크, 데이터베이스 등에서 발생하는 병목 지점의 원인을 확인확장성 확인 : 트래픽 증가에 따라 시스템이 얼마나 안정적으로 확장 가능한지 확인최대 용량 파악..

트랜잭션의 범위 분석과 관심사 분리`콘서트 예약 서비스`에서 파사드 패턴을 활용하여 유즈케이스를 작성하면서 느낀 점은 다음과 같습니다.아 이거 너무 뚱뚱한데.. 왜이렇게 찝찝히지..? 이게 맞아..? 온동네 도메인들이 여기 다 모였는데.. 근데 이게 맞긴해.. 이유는 파사드 패턴을 적용해 application 계층의 유즈케이스를 작성할 경우,각 도메인 역할을 수행하는 객체들을 호출하여 하나의 유즈케이스를 구성하게 되는데,이때 한 트랜잭션 내에 너무 많은 역할들이 묶이게 되면서 어딘가 보기 불편한 코드가 됐기 때문입니다. 이번에 이 트랜잭션 범위를 분석하여 관심사 분리가 가능한지 검토해보고자 합니다.  | 트랜젝션 범위 분석기존의 `결제` 기능의 흐름은 아래와 같다. 모두 하나의 트렌젝션에서 동작하게 된다..

인덱스로 쿼리 성능 개선 해보기기존에 구현한 `콘서트 예약 서비스`를 쿼리 성능 최적화를 위해 많이 사용되는 컬럼에 `인덱스`를 활용하여, 이에 따른 쿼리 속도 개선 결과를 확인하고자 합니다.  | 인덱스가 필요한 쿼리 확인현 프로젝트에서 사용하는 쿼리는 모두 `findById` or `save`입니다.따라서, byId에서 사용할 논리적 foreign key를 인덱스로 잡으면 될 것으로 판단했습니다. 프로젝트에서 where 등 복잡한 쿼리가 없던 이유는 모두 비지니스 로직으로 풀었기 때문입니다. 개인적으로 해당 방식을 선택한 이유는 아래와 같습니다.스키마 등 값이 변경됐을 때 보다 유연하게 대응할 수 있음비슷한 기능의 재사용이 가능DB 부하를 줄일 수 있음로직에서 성능을 올릴 수 있는 방법이 다양함| I..

Redis vs RDBMS 성능 테스트기존에 구현한 `콘서트 예약 서비스`를 성능 최적화를 위해 DB -> 메모리 기반인 Redis 로 교체하고, 이에 따른 성능 테스트를 통한 결과를 확인하고자 합니다.  | Redis데이터 처리 속도가 엄청 빠른 *NoSQL 데이터베이스* NoSQL : key - value 형태로 저장하는 데이터베이스 | 장점`인메모리`에 모든 데이터를 저장하기 때문에 데이터 처리 성능이 굉장히 빠르다.이유는, 디스크 보다 메모리의 데이터 처리 속도가 월등히 빠르기 때문이다.구분RDBMS(ex. MySQL)Redis데이터 저장공간디스크메모리(RAM)    | 성능 최적화 포인트구분대기열 입장 토큰나의 대기 순번 조회개선 포인트만료시간이 5분인 wait 토큰 생성ZRank를 사용하여, ..

Cache Aside, Write Around 전략의 한계점 / 해결 방법 | 캐시된 데이터와 DB에 저장된 데이터의 불일치 Cache Asdie와 Write Around 전략을 같이 썼을 때의 한계점 중 하나는 캐시된 데이터와 DB 데이터가 일치하지 않을 수 있다는 점이다즉, 데이터의 일관성 보장 할 수 없다 예를들어 블로그명을 `A` -> `B`로 변경했으나, 여전히 A인 경우이다.생각해보면 데이터베이스에는 B로 변경됐지만, 조회는 캐시에 저장해 두어 여전히 A로 노출되는 상황(= 데이터 불일치)  💡 그렇다면, DB와 레디스에 모두 업데이트하면 될까? 아니다. 캐시는 메모리(RAM)에 저장되기 때문에 디스크보다 용량이 작다.  | 해결방법1. 캐시를 적용시키기에 적절한 데이터를 정한다.자주 조회되..

Cache Aside (= Look Aside, Lazy Loading) 전략데이터를 조회할 때 주로 사용레디스에서 먼저 조회하고, 없으면 데이터베이스에서 조회하고 & 레디스에 저장하는 전략캐시에 데이터가 있을 경우(= Cache Hit)캐시에 데이터가 없을 경우 (= Cache Miss) ▼ 게시판 서비스를 예제로 Cache Aside 작동 방식을 이해하기더보기처음 게시판 서비스를 배포했기 때문에 데이터베이스와 레디스에는 아무런 데이터도 저장이 안 되어 있음신규 게시글 작성으로 데이터 저장데이터베이스에 저장(레디스 저장 x)사용자가 데이터를 조회하려고 요청이 때, 레디스부터 조회레디스에 데이터가 없다면(= Cache Miss), 데이터베이스에서 데이터 조회해서 응답데이터베이스로부터 조회한 데이터를 응답..

캐시(Cache)원본 저장소보다 더 빠르게 가져올 수 있는 *임시 데이터 저장소* 데이터를 임시로 복사해두는 Storage 계층 💡 우리 주변에서 볼 수 있는 Cache 사례DNS : 웹사이트 IP 를 기록해두어 웹사이트 접근을 위한 DNS 조회 수를 줄인다.CPU : 자주 접근하는 데이터의 경우, 메모리에 저장해두고 빠르게 접근할 수 있도록 한다.CDN : 이미지나 영상과 같은 컨텐츠를 CDN 서버에 저장해두고 애플리케이션에 접근하지 않고 컨텐츠를 가져오도록 해 부하를 줄인다.  캐싱(Caching)캐시(임시 데이터 저장소)에 접근하여, 데이터를 빠르게 가져오는 방식