1편에서 이야기했듯, 나는 초기에 테스트를 잘못 이해한 방식으로 사용하고 있었다.테스트에서 기능을 만들어보지만 실제 프로덕션 코드는 다시 처음부터 작성하는 구조였고,테스트는 참고용 코드에 불과했다.하지만, 이 시행착오를 겪은 덕분에, 테스트를 제대로 활용하는 방식,즉 테스트 → 설계 → 프로덕션 코드 승격이라는 진짜 TDD적 흐름을 이해하게 되었다.이 글에서는 내가 테스트를 활용하는 방식을 어떻게 바꿨고,그 과정에서 어떤 설계 개선이 이루어졌는지 기록해보려고 한다. # 테스트에서 시작하고, 설계로 이어지는 흐름을 만들다예전처럼 테스트에서 기능을 만들고 프로덕션에서 처음부터 다시 만드는 대신,나는 다음과 같은 흐름으로 개발을 진행하기 시작했다.테스트에서 간단한 프로토타입을 작성하고 원하는 동작을 검증한다..

테스트의 시작 개발자인 경우, 누구나 자신이 만든 기능이 정상 수행하는지 확인하는 절차를 가져야한다.처음에는 만들면서 케이스들을 고려하여 구현하게되고, 마무리 단계에서 몇가지의 테스트들을 통해 직접 검증하는 방식으로 확인하였다.하지만, 그런 검증 방식에서 당연히 되야한다고 생각했던것들에서 항상 1~2개씩 놓치게되어 다시 재배포하는 경우가 발생하게 되었다.처음에는 QA단계에서 발생하여 다행이다라고 생각을 하게되었지만, 몇번 이런 일들이 생기게되니 점차 스스로도 신뢰하지 못하는 단계에 이르게 되었다.그래서 테스트의 필요성을 깨닫고, 테스트를 시작하며 직면한 문제(?)에 대해서 기록해보고자 한다. # 테스트를 해야겠다고 느낀 이유 1. 완성했다고 생각한 기능에서 계속되는 문제 발생 기능을 구현하고 "이제 동작..

전체 아키텍처 흐름도 이미지 Spring AOP 기반 유효성 검증 처리 구조 정리Spring에서 DTO 유효성 검증을 처리할 때, 기본 제공되는 BeanValidation만으로는 부족한 경우가 있다.이럴 때 커스텀 Validator를 추가로 적용할 수 있도록 구조를 설계하며, 두 가지 방식을 함께 활용한다.✅ BeanValidation + CustomValidation을 함께 사용하도록 구성한다.✅ 유효성 검증을 AOP로 감싸 공통 포맷으로 처리하도록 만든다.✅ 어노테이션(@CustomValidate)을 통해 자동으로 Validator를 스캔하고 매핑한다. 전체 흐름 개요Controller (with @CheckValidation) ↓ValidationAspect (AOP) ├─ B..

Spring Bean Validation과 커스텀 어노테이션 Spring Boot에서 사용자 입력값을 검증할 때 가장 많이 사용하는 방식은 Bean Validation이다. 간단한 유효성 조건은 어노테이션 한 줄로 처리할 수 있고, 복잡한 로직이 필요한 경우에는 커스텀 유효성 어노테이션을 직접 만들어 적용할 수 있다.이 글에서는 Bean Validation의 기본 사용법과 함께 @PasswordValidate라는 커스텀 어노테이션을 만들어서 비밀번호 조건을 검사하는 과정을 정리해본다. 1. DTO에 유효성 어노테이션 적용public static class TestV2Dto { // spring bean validation (기본) @NotBlank private String name; ..

Spring에서 Validator를 이용한 커스텀 유효성 검사와 BindingResult 활용Spring에서는 사용자 입력 값을 검증하기 위해 Bean Validation(JSR-380)을 많이 사용하지만, 더 복잡한 조건이 있거나 커스터마이징이 필요한 경우에는 org.springframework.validation.Validator를 직접 구현하여 사용할 수 있다. 이 포스팅에서는 Validator를 이용한 유효성 검사와 BindingResult를 통해 검증 결과를 처리하는 방법을 소개한다. 1. Validator 인터페이스 구현하기 Spring의 Validator 인터페이스는 두 가지 메서드를 구현해야 한다:supports(Class clazz): 이 Validator가 어떤 클래스 타입을 지원하는지..

트랜잭션(Transaction) 실패 경험을 통한 내용 정리1.. 예외처리로인한 Transaction Proxy 실패2. self Call로 인한 @Transactional 실패 트랜잭션(Transaction) 개요스프링 프레임워크에서 트랜잭션은 ACID(원자성·일관성·격리성·지속성) 규칙을 따르며,하나의 처리 흐름이 모두 성공해야 커밋되고, 중간에 문제가 발생하면 전부 롤백되도록 보장주로 @Transactional 애노테이션을 통해 스프링 AOP 프록시가 트랜잭션 경계를 관리원자성(Atomicity): 작업 전체가 성공하거나, 하나라도 실패하면 모두 롤백일관성(Consistency): 트랜잭션 전후에 데이터베이스 일관성이 유지격리성(Isolation): 동시성 제어를 통해 트랜잭션 간 간섭을 방지지..