가지가지하네

테스트 커버리지란? 작성한 테스트 코드가 애플리케이션의 몇 % 코드를 실행했는지를 나타내는 지표 라인 커버리지(Line Coverage): 몇 %의 코드 라인이 실행되었는지브랜치 커버리지(Branch Coverage): 조건문 등 분기문의 실행 비율메서드 커버리지(Method Coverage): 메서드 단위로 호출된 비율IntelliJ에서 테스트 커버리지 실행하기프로젝트 우클릭 → 그 외 실행/디버그 → 커버리지로 ""에 있는 테스트 실행 실행하면우측에 커버리지 탭이 생긴다 ! 요소별 커버리지 퍼센트 확인 가능 디렉토리 목록에서도 확인 가능 코드에서도 테스트 커버 여부 확인 가능초록색은 테스트가 실행된 코드 줄빨간색은 테스트되지 않은 코드 줄 추가 참고 자료: JaCoCo 로 테스트 커버리지 확..

1. 문제 인식 및 정의Lv 2 단계에서 특정 메서드의 fetch join 구문을 리팩토링했지만,여전히 여러 곳에 fetch join JPQL이 남아있는 상황 이를 리팩토링 하고자 함 JPQL fetch join 방식 단점 쿼리가 복잡하고 길어져 가독성 저하중복된 fetch join 코드가 여러 곳에 존재페치 전략 변경 시 일일이 수정해야 해 유지보수 어려움재사용이 어렵고 관리가 번거로움2. 해결 방안JPQL fetch join 방식 -> @EntityGraph로 대체동일한 효과의 쿼리를 JPQL 없이도 적용 가능메서드 명 기반 쿼리 작성 시에도 연관 엔티티를 즉시 로딩(fetch join) 가능3. 해결 완료- JPQL fetch join 쿼리 대신 @EntityGraph 어노테이션 적용- 메서드 명..

1. 문제 인식 및 정의여러 서비스 클래스에서 동일한 형태의 예외 로직이 반복되고 있는 상황 확인 발생가능한 문제유지보수성 저하: 로직 변경 시 모든 중복 위치를 찾아 수정해야 한다.휴먼 에러 위험 증가: 일부 위치에서 변경을 놓치면 버그로 이어진다.가독성 저하: 핵심 로직보다 반복된 부수 코드가 많아져 흐름이 뚝뚝 끊긴다.2. 해결 방안중복 코드를 제거하고, 공통 로직은 한곳에서 관리할 수 있도록 리팩토링한다.서비스 계층에서는 각 도메인에 대한 책임을 명확히 분리 한다.User 관련 공통 로직은 UserService 에 정의Todo 관련 공통 로직은 TodoService 에 정의도메인 객체가 필요한 서비스들은 더 이상 각자의 Repository를 직접 사용하지 않고, 해당 도메인의 Service에서 ..

이번 코드 개선 과제에서"어드민 사용자만 접근할 수 있는 특정 API에 접근할 때마다 접근 로그를 기록해야 한다"는 요구사항이 주어졌다. 구현 가능 방식은 두가지인데 Interceptor AOP(Aspect-Oriented Programming)두 방식 모두 공통 관심사를 분리할 수 있는 기술이지만, 적용 범위와 방식에는 명확한 차이가 있다. 두 기술 중 어떤 방식이 이번 과제 더 적합한지 분석하여 정리해보고자 한다. 참고: https://gajicoding.tistory.com/374 Interceptor vs AOP(Aspect Oriented Programming)Spring에서는 공통 기능을 모듈화하기 위한 여러 방법을 제공한다.그 중 많이 사용되는 두 가지가 바로 Interceptor와 AOP..

Spring에서는 공통 기능을 모듈화하기 위한 여러 방법을 제공한다.그 중 많이 사용되는 두 가지가 바로 Interceptor와 AOP(Aspect-Oriented Programming)이다.이 글에서는 두 개념의 차이점과 사용 목적을 명확히 정리하고자 한다. Interceptor란?Spring MVC에서 제공하는 컴포넌트주로 HTTP 요청/응답 흐름을 가로채기 위해 사용DispatcherServlet에서 Controller로 가기 전/후에 동작 동작 시점preHandle() – Controller 실행 이전postHandle() – Controller 실행 이후, View 렌더링 전afterCompletion() – View 렌더링 이후 장점웹 요청(Request/Response)에 특화되어 있어 인증..

AOP란?핵심 비즈니스 로직과 부가적인 관심사(로깅, 트랜잭션, 보안 등)를 분리하여 모듈화하는 프로그래밍 기법관심사의 분리(Separation of Concerns, SoC)를 통해 코드의 재사용성, 유지보수성을 높인다AOP의 필요성로깅, 예외 처리, 트랜잭션 관리 등은 여러 클래스에서 반복적으로 등장한다.이를 각 클래스에 흩뿌려 두면 코드가 중복되고, 수정이 어려워진다.AOP를 사용하면 공통 기능을 한 곳에 모아 관리할 수 있다.AOP 핵심 용어Aspect: 공통 기능(로깅, 트랜잭션 등)을 모듈화한 단위Join Point: Advice가 적용될 수 있는 지점(메서드 실행 등)Pointcut: Join Point 중 실제 Advice가 적용될 지점을 지정Advice: 언제(언제 실행되는지: befor..

@EntityGraph란?JPA의 Entity Graph 기능을 Spring Data JPA에 적용한 어노테이션지연 로딩(LAZY) 필드들을 명시적으로 fetch join 하도록 설정할 수 있다.JPQL의 join fetch 없이 리포지토리 메서드 수준에서 연관 엔티티를 즉시 로딩할 수 있도록 도와준다.기본 사용법attributePaths: 즉시 로딩하고 싶은 연관 엔티티 경로내부적으로 JPQL의 join fetch와 유사한 SQL이 실행됨public interface MemberRepository extends JpaRepository { @EntityGraph(attributePaths = {"team"}) List findAll(); // findAll 호출 시 team도 함께 조회됨}예..

JaCoCo란?Java Code Coverage의 약자로, 테스트 코드가 실제 애플리케이션 코드를 얼마나 실행했는지 측정해주는 도구.build.gradle 설정 플러그인 적용plugins { id 'jacoco' // Java Code Coverage} 버전 및 리포트 경로 지정jacoco { toolVersion = '0.8.13' reportsDirectory = layout.buildDirectory.dir('reports/jacoco')} 테스트 후 커버리지 리포트 생성tasks.named('test') { useJUnitPlatform() finalizedBy jacocoTestReport} 커버리지 기준 설정 (빌드 실패 조건)jacocoTestCoverageV..

✅ 목차테스트를 위한 Annotation 단위 테스트 작성 원칙 Mocking 개념 및 사용 이유 행위 검증 vs 상태 검증 [예제] 단위 테스트 - Repository[예제] 단위 테스트 - Service[예제] 단위 테스트 - Controller[예제] 유틸 테스트[예제] 통합 테스트1. 테스트를 위한 Annotation @DataJpaTestJPA 관련 컴포넌트만 로드하여 Repository 레이어 단위 테스트용기본적으로 인메모리 DB(H2 등) 사용@ExtendWithJUnit5 확장 기능 적용용주로 MockitoExtension과 함께 Service, 클래스 단위 테스트에 사용@WebMvcTestWeb Layer (Controller, Filter 등) 테스트용@Controller, @Contr..

✅ 목차테스트를 왜 해야할까? 테스트 코드는 왜 필요할까?테스트 코드 작성의 원칙테스트의 종류테스트 코드는 어떻게 작성해야할까?1. 테스트를 왜 해야할까? 기능이 요구사항대로 잘 동작하는지 확인하기 위함완벽한 코드를 한 번에 작성하기 어렵고 예상치 못한 입력으로 장애가 발생할 수 있기 때문에 다양한 케이스를 테스트로 검증해야 한다. 테스트 방법Swagger, Postman 등으로 다양한 케이스를 직접 확인QA 과정에서 UI, 프론트, 서버를 아우르는 테스트테스트 코드를 작성해 자동화된 검증 수행 2. 테스트 코드는 왜 필요할까? 버그를 조기에 발견개발 단계에서 버그를 미리 찾아 수정 가능코드 품질 개선테스트 작성이 어려운 코드를 개선하게 되고, 클래스 역할과 책임을 명확히 하여 클린 코드 작성에 도움배포..