[Spring] 스프링 입문 - 코드로 배우는 스프링 부트, 웹 MVC, DB 접근 기술 3. 회원 관리 예제 - 백엔드 개발

💡 본 게시글은 김영한님의 인프런(Inflearn) 강의 스프링 입문 - 코드로 배우는 스프링 부트, 웹 MVC, DB 접근 기술에 대한 수강 기록용으로 작성되었습니다.

1. 비즈니스 요구사항 정리

❗ 아직 데이터 저장소가 선정되지 않았다는 전제하에 MemberRepository를 인터페이스(interface)로 만들 것이다. 향후에 JDBC, MyBatis, JPA 등으로 바꿔 끼울 수 있도록 인터페이스(interface)로 설정해두자.

• 컨트롤러(controller): API 생성 시 쓰이는 등 웹 MVC 컨트롤러 역할
• 서비스(service): 핵심 비즈니스 로직 구현
• 리포지토리(repository): 데이터베이스에 접근하여 도메인 객체를 DB에 저장 및 관리
• 도메인(domain): 회원,주문,쿠폰 등과 같이 주로 데이터베이스에 저장 및 관리되는 비즈니스 도메인 객체

---

2. 회원 도메인과 리포지토리 만들기

public class MemoryMemberRepository implements MemberRepository {

	private static Map<Long, Member> store = new HashMap<>();
	private static long sequence = 0L;
   
	...
	@Override
	public Optional<Member> findById(Long id) {
 		return Optional.ofNullable(store.get(id));
 	}
    
	@Override
	public Optional<Member> findByName(String name) {
		return store.values().stream()
				.filter(member -> member.getName().equals(name))
				.findAny();
	}
    ...
}

• 회원 리포지토리 메모리 구현체이다. 실무에서는 동시성 문제를 고려해 HashMap 대신 ConcurrentHashmap을, Long 대신 AtomaticLong 사용함을 유념하자. 여기서는 간단한 예제를 만들기 위함이므로 HashMap, Long이 쓰인다.
• Optional<T>는 NPE(NullPointerException)를 방지할 수 있도록 도와주는 래퍼 클래스(wrapper class)이다.
  • Optional<T> 클래스에 정의된 private final T value; 필드는 결과가 null이 아닌 경우에 한하여 그 값(value)을, null일 경우 존재하는 값이 없음을 나타낸다(If non-null, the value; if null, indicates no value is present).
  • 결과값으로 null이 반환될 가능성이 있을 때는 Optional.ofNullable()로 감싸서 처리할 수 있다.

---

3. 회원 리포지토리 테스트 케이스 작성

3-1. 테스트 클래스 생성

• 테스트 클래스는 src/test/java 하위 폴더에 생성하며, 테스트 클래스의 이름 끝엔 'Test'를 붙인다.
  • ①패키지와 클래스를 차례로 직접 생성하거나, ②인텔리제이(IntelliJ) 환경이라면 테스트 대상이 되는 클래스에서 단축키(ctrl + shift + t) 눌러 Create New Test 처리할 수 있다.
  • 테스트 클래스는 굳이 public으로 선언하지 않아도 된다.
• 테스트 케이스 이름은 한글로 작성해 보다 직관적으로 쓸 수가 있다.
• 테스트 케이스마다 given/when/then으로 구분지어 주석을 달아두면 좋다.
• 테스트는 정상 플로우가 중요한 만큼 예외 플로우도 중요하다. 즉 맞는 로직만 검사하는 데 그치지 않고 일부러 예외를 발생시키고, 예외가 빚은 결과 역시 확인해야 하는 것이다.

---

3-2. Assertions(JUnit/AssertJ): assertThat

• Assertions을 제공하는 라이브러리로서 JUnit과 AssertJ가 자동 임포트(import) 목록에 자리한다.

Assertions.assertEquals(result, member);

• JUnit 기반으로는 assertEquals(a, b)를 써서 a가 b 맞는지를 확인할 수 있다.

assertThat(result).isEqualTo(member);
assertThat(result.size()).isEqualTo(2);

• AssertJ에서는 assertThat(a).isEqualTo(b)로 작성한다. 인자 타입에 맞는 Assert 클래스를 반환해 필요한 메소드만 분류돼 있고, 나아가 메소드 자동완성이 지원돼 편리하다는 장점이 있다. 이번 강의에서도 AssertJ 라이브러리를 임포트(import)해 쓰도록 한다.
• Assertions에 단축키(alt + enter) 쳐서 static으로 선언해두면 Assertions.assertThat() → assertThat으로 간편히 사용 가능하다.

---

3-3. @AfterEach

class MemoryMemberRepositoryTest {

	MemoryMemberRepository respository = new MemoryMemberRepository();

	@AfterEach
	public void afterEach() {
		respository.clearStore();
	}
}

• @AfterEach 어노테이션을 사용하면 각 테스트가 종료될 때마다 명시된 기능이 실행된다.
• 테스트 메소드의 순서는 보장되지 못하며, 각각의 테스트 메소드는 순서와 관계 없이, 서로간 의존 관계 없이 독립적으로 실행되어야 마땅하다. 따라서 테스트간 충돌이 없도록 한 차례 실행된 뒤 공용 데이터를 깔끔하게 지워주는 작업이 요구된다.

---

3-4. TDD

❗ 강의 내용과는 다르지만, 테스트 주도 개발에 대한 설명을 덧붙인다. 테스트 관련해서는 꼭 깊이 있게 공부해보기를 권장하는 바이다.

• 테스트 클래스를 작성한 다음 → 리포지토리(repository)를 작성하는 순서로 뒤집을 수도 있다. 예를 들어 별모양 작품을 만들고자 할 때 그것을 검증할 수 있는 틀 먼저 만들어놓고 → 작품을 빚어서 그 틀에 맞는지 안 맞는지 확인할 수도 있다는 뜻이다.
• 테스트를 작성한 뒤 구현 클래스를 만드는 작업 과정을 일컬어 테스트 주도 개발(TDD, Test Driven Development)라고 부른다.

---

4. 회원 서비스 개발

4-1. DI 적용

❗ 의존성 주입(DI, Dependency Injection) 통해 직접적인 결합 관계를 피하고 유지보수성을 높일 수 있다.

public class MemberService {

	private final MemberRepository memberRepository = new MemoryMemberRepository();
}

• MemberService가 MemoryMemberRepository 인스턴스를 직접 생성한 예시이다. 아래와 같이 개선이 필요하다.

public class MemberService {

	private final MemberRepository memberRepository;
    
	public MemberService(MemberRepository memberRepository) {
		this.memberRepository = memberRepository;
	}
	...
}

• MemberRepository에 대한 의존성을 주입 받도록 작성한 예시이다.
• 서비스 테스트와 서비스 클래스간에도 같은 인스턴스를 참조할 수 있도록 해야 알맞은 결과를 얻을 수 있다. 각각 다른 인스턴스를 대하고 있다면 데이터마저 상충하는 결과로 이어질 수 있기 때문이다.

---

4-2. 메소드 추출

public Long join(Member member) {
	Optional<Member> result = memberRepository.findByName(member.getName());
	result.ifPresent(m -> {
		throw new IllegalStateException("이미 존재하는 회원입니다.");
	});

	memberRepository.save(member);
	return member.getId();
}

• Optional<T> 인스턴스를 사용하는 것은 사실 가독성 문제로 권장되지 않는 바이다. 따라서 참조 변수를 만들어 할당하기 보다는 아래와 같이 직접 작성하는 것이 좋다.
• 또, Optional<T> 인스턴스에서 값을 호출할 때 역시 get()보다는 orElseGet()을 사용해 값이 존재하는 경우에만 꺼내오도록 쓰는 것이 바람직하다.

private void validateDuplicateMember(Member member) {
	memberRepository.findByName(member.getName())
		.ifPresent(m -> {
			throw new IllegalStateException("이미 존재하는 회원입니다.");
		});
}

• 인텔리제이(IntelliJ)에서 메소드 로직 추출할 때는 해당되는 범위만큼 드래그한 후 → 단축키(alt + enter)를 눌러 선택지로 생긴 메소드 추출(Extract Method)을 활용하면 된다.

---

5. 회원 서비스 테스트

5-1. @BeforeEach

class MemberServiceTest {

	MemberService memberService;
	MemoryMemberRepository memberRepository;

	@BeforeEach
	public void beforeEach() {
		memberRepository = new MemoryMemberRepository();
		memberService = new MemberService(memberRepository);
	}
}

• @BeforeEach 어노테이션을 명시한 메소드는 각 테스트 실행 전에 호출된다.
• 이를 통해 새로운 객체를 생성하고, 의존 관계 역시 항상 새롭게 부여돼 테스트 케이스간 독립적 실행의 기반을 닦는다.

---

5-2. Assertions(AssertJ): assertThrows

try {
	memberService.join(member2);
	fail();
} catch(IllegalStateException e) {
	assertThat(e.getMessage()).isEqualTo("이미 존재하는 회원입니다.");
}

• 같은 이름을 가진 member1, member2가 있다. 중복 회원 검증 중 예외가 제대로 발생하는지 테스트를 진행해 보자.
• 첫 번째 방법은 try-catch문으로 감싼 뒤 assertThat(a).isEqualTo(b)); 통해 발생한 예외 메시지가 예상과 같은지 검증하는 것이다.

assertThrows(IllegalStateException.class, () -> memberService.join(member2));

IllegalStateException e = assertThrows(IllegalStateException.class, () -> memberService.join(member2));
assertThat(e.getMessage()).isEqualTo("이미 존재하는 회원입니다.");

• 두 번째 방법은 assertThrows(예외, () -> 로직)를 활용하는 것이다. 현재 주어진 조건에서 로직을 실행하거든 이러한 예외가 발생한다는 의미로 기술한다.
  • 따라서 명시된 예외와 일치할 경우 성공, 불일치하면 실패로 이어진다.
• 메시지에 대한 검증 역시 가능하다. assertThrows 결과를 인스턴스로 만들어준 뒤 → assertThat으로 기대하는 메시지가 맞는지 한 번 더 확인하는 방법을 통한다.
  • 인텔리제이(IntelliJ) 환경에서 인스턴스를 생성할 때는 단축키(ctrl + alt + v)를 쓸 수 있다.