기록

테스트 코드에서 assertThat을 사용할 때 가장 큰 장점은 가독성과 다양한 조건 메서드입니다. 아래 글에서는 assertThat과 함께 자주 사용하는 주요 메서드를 정리하고 예제 코드를 통해 각각의 메서드가 어떤 상황에 적합한지 설명하겠습니다.1. 기본 비교 메서드1-1. isEqualTo(expected)실제 값이 기대 값과 같은지 비교합니다. 가장 기본적인 비교 메서드입니다.assertThat(10).isEqualTo(10);assertThat("Hello").isEqualTo("Hello");1-2. isNotEqualTo(expected)실제 값이 기대 값과 같지 않은지 비교합니다.assertThat(10).isNotEqualTo(5);assertThat("Hello").isNotEqualT..

시작하면서이번 포스팅에서는 C++ Builder를 사용하여 스레드를 활용해 특정 기간마다 로그 파일을 작성하는 프로그램을 구현한 과정을 소개합니다. 스레드의 간단한 사용 예제와 콜백패턴을 사용한 프로그램 구조 개선을 다루겠습니다.본문1. Thread와 TimerTimer는 UI와 연동된 작업을 수행하는 데 유리합니다. 그 이유는 Timer가 UI 스레드와의 통신을 쉽게 할 수 있기 때문입니다. 반면, Thread는 CPU 집약적인 작업이나 I/O 작업에 적합합니다. 파일을 쓰거나 옮기는 작업은 Thread를 활용하는 것이 유리합니다.하지만 Thread와 Timer 외에도 Task나 Async/Await 같은 비동기 패턴을 사용할 수 있습니다. 이러한 대안들은 코드의 가독성을 높이고, 복잡한 스레드 관리 ..

테스트 코드를 작성하다 보면 여러 가지 질문이 떠오릅니다. 그중에서도 특히 많은 고민을 불러일으키는 질문은 아래의 세 가지입니다:테스트에서 외부 요소(현재 시간 등)는 어떻게 제어해야 하는가?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. 문제 상황얼마 전, Kafka Consumer가 특정 메시지를 받아 DB에 저장하는 기능을 담당하는 서비스를 운영하던 중 Dto를 수정하는 일이 생겼습니다. 테스트 코드를 위해 생성자가 필요했고, 이에 DTO 클래스에 @Builder 어노테이션을 추가했습니다. 이를 통해 테스트 코드에서 MyDto.builder().dataId("testId").name("testName").build()와 같이 편리하게 객체를 생성할 수 있었습니다.수정된 코드는 다음과 같습니다:@Getterpublic class MyDto { private String dataId = "11111"; private String name = "22222"; // 추가 시작 @Builder public M..

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