기록

테스트 코드를 작성하다 보면 여러 가지 질문이 떠오릅니다. 그중에서도 특히 많은 고민을 불러일으키는 질문은 아래의 세 가지입니다:테스트에서 외부 요소(현재 시간 등)는 어떻게 제어해야 하는가?Private 메서드는 테스트를 해야 하는가?테스트에서만 사용하는 함수나 코드는 어떻게 처리해야 하는가?외부 요소는 어떻게 제어해야 하는가?외부 요소가 테스트에 미치는 영향코드에서 외부 요소(예: 현재 시간 LocalDateTime.now, 환경 변수, 외부 API 호출 등)를 직접 호출하면, 테스트 작성이 어려워지고 유지보수에 악영향을 줄 수 있습니다. 특히 외부 요소를 직접 호출하면 다음과 같은 문제가 발생합니다:테스트 결과의 불안정성 : 테스트가 실행될 때마다 현재 시간이 달라지기 때문에 결과가 일관되지 않을 ..

1. 도입: 스프링 부트가 뜨는 조건과 배경스프링 부트 애플리케이션은 테스트 환경 설정에 따라 새로 기동됩니다. 동일한 설정에서는 애플리케이션 컨텍스트를 재사용하지만, 아래와 같은 조건이 달라지면 새로운 컨텍스트가 생성됩니다:Active Profiles 차이: 서로 다른 프로파일(@ActiveProfiles)이 설정된 경우.Mock 처리한 빈 차이: @MockBean 또는 @MockMvc 설정이 다를 경우.테스트 방식 차이: @SpringBootTest, @WebMvcTest 등 사용된 테스트 어노테이션이 다를 경우.이로 인해 서버가 반복적으로 기동되면서 테스트 수행 시간이 길어질 수 있습니다. 이를 방지하려면 환경을 통합하여 컨텍스트 재사용성을 높이는 전략이 필요합니다.2. 문제와 해결책문제점테스트 환..

시작하면서테스트는 독립적으로 실행되어야 하지만, 공유 자원을 사용할 경우 문제가 발생할 수 있습니다. 예를 들어, @BeforeAll, @BeforeEach로 테스트 환경을 설정하고 모든 테스트에서 같은 데이터를 사용하면, 한 테스트에서 변경된 데이터가 다른 테스트에 영향을 줄 수 있습니다.Test Fixture의 개념Test Fixture란 테스트를 위해 필요한 상태로 고정된 일련의 객체나 데이터를 말합니다.Given 절에서 필요한 객체를 생성하는 과정이 반복되다 보면 중복 코드가 늘어날 수 있습니다.하지만 중복을 제거하려는 목적으로 모든 데이터를 공통화하면 공유 자원 문제로 인해 테스트 독립성이 깨질 위험이 있습니다.Test Fixture 구성과 클렌징 전략Test Fixture 구성 시 주의점@Be..

각 테스트는 하나의 목적만 가진다테스트 코드는 단순히 코드가 잘 작동하는지 확인하는 데서 끝나는 것이 아니라, 코드의 의도와 동작 방식을 명확히 보여줄 수 있어야 합니다.이를 위해 하나의 테스트는 하나의 목적만 가져야 하며, 여러 목적을 포함하면 테스트가 복잡해지고 의도를 이해하기 어려워집니다.잘못된 테스트 코드 예제 : 반복문과 조건문을 포함한 예제아래는 반복문과 조건문을 포함한 잘못된 테스트 코드 예제입니다. 이 코드는 여러 케이스를 하나의 테스트에 담아 작성되었기 때문에 가독성과 유지보수성이 떨어집니다.@DisplayName("사용자 권한이 특정 권한에 해당하는지 확인한다.")@Testvoid checkUserRole() { // given UserRole[] roles = UserRol..

1. Mock을 사용하는 상황과 사용하지 않는 상황1.1 Mock을 사용하는 상황외부 시스템과 연계되는 테스트에서 Mock 객체를 사용하면 외부 의존성을 제거하고 독립적으로 동작을 검증할 수 있습니다. 예를 들어, 이메일 전송, API 호출 등 외부 서비스에 의존하는 로직은 Mock 객체로 대체하여 테스트에서 외부 시스템의 영향을 배제해야 합니다.1.2 Mock을 사용하지 않는 상황내부 로직만 검증하는 테스트에서는 실제 객체를 사용하여 테스트를 수행하는 것이 적합합니다. 이 경우 실제 객체의 동작을 통해 로직의 정확성을 확인할 수 있습니다.1.3 Classicist vs Mockist 논쟁Mock 사용 여부와 관련된 논쟁으로 Classicist 접근법과 Mockist 접근법이 있습니다.Classicist..

CQRS 개념CQRS(Command Query Responsibility Segregation)는 소프트웨어 아키텍처 스타일 중 하나로, 시스템의 명령(Command)과 조회(Query)를 분리하여 각자의 책임을 명확히 정의합니다. 이는 대규모 애플리케이션에서 복잡성을 줄이고 성능을 최적화하기 위한 강력한 설계 방식으로, 다음과 같은 특징이 있습니다:명령(Command): 데이터 변경 작업을 처리하며, 데이터베이스에 새로운 데이터를 삽입하거나 기존 데이터를 수정 및 삭제하는 역할을 합니다. 이러한 작업은 주로 비동기적으로 처리되며, 트랜잭션을 통해 데이터의 일관성을 보장합니다.조회(Query): 데이터를 읽는 작업으로, 시스템 상태를 변경하지 않고 필요한 정보를 클라이언트에게 반환합니다. 조회 작업은 일..

시작하면서Spring Framework에서는 Bean Validation을 통해 데이터 유효성을 간편하게 검증할 수 있습니다. 이 글에서는 주요 어노테이션, Validation 적용 위치, 그리고 실제 사용 사례를 중심으로 Spring Bean Validation을 활용하는 방법을 알아보겠습니다.1. 주요 어노테이션Bean Validation에서 자주 사용되는 어노테이션은 다음과 같습니다:@NotNull: 값이 null이 아니어야 함.@NotEmpty: 빈 문자열("")이나 null이 아닌 값이어야 함 (컬렉션, 배열 등도 지원).@NotBlank: 공백만으로 이루어진 문자열이 아닌 값을 검증.@Positive: 양수 값만 허용.@Size(min = , max = ): 문자열, 컬렉션, 배열 등의 크기 ..

시작하면서Spring 애플리케이션에서 각 레이어는 명확한 책임 분리를 통해 유지보수성과 테스트 가능성을 향상시키며, 각 레이어에 적합한 테스트 전략을 적용할 수 있습니다. 예를 들어, Controller Layer는 클라이언트 요청을 처리하고 Service Layer를 호출하며, Service Layer는 비즈니스 로직을 처리하고 Repository Layer는 데이터 접근을 담당합니다. 아래는 Controller, Service, Repository 레이어 각각의 테스트 방법과 그 전략을 설명합니다.1. Controller Layer역할:클라이언트의 요청(Request)을 수신하고, 적절한 Service를 호출하여 응답(Response)을 생성합니다.입력값 검증과 같은 최소한의 논리만 처리합니다.테스트..